The KOA Remote Voting System:
A Summary of Work To-Date
Joseph R. Kiniry, Alan E. Morkan, Dermot Cochran and Fintan Fairmichael1 ,
Patrice Chalin2 , Martijn Oostdijk and Engelbert Hubbers3
1
School of Computer Science and Informatics
University College Dublin
Belfield, Dublin 4, Ireland
2
Department of Computer Science and Software Engineering
Concordia University
Montreal, Quebec, H3G 1M8, Canada
3
Nijmegen Institute of Information and Computing Sciences
Radboud University Nijmegen
Postbus 9010, 6500GL Nijmegen, The Netherlands
Abstract. Remote internet voting incorporates many of the core challenges of
trusted global computing. In this paper, we present the Kiezen op Afstand4 (KOA)
system. KOA is a Free Software, remote voting system developed for the Dutch
government in 2003/2004. In addition to being Open Source, it is also partially
formally specified and verified. This paper summarises the work carried out to
date on the KOA system. It charts the evolution of the system, from its initial conception by the Dutch Government, through to its current status. It also describes
a roadmap of milestones towards completing its next release: a Free Software,
general-purpose, formally specified and verified internet voting system, that incorporates Proof Carrying Code technology for software update and allows trustworthy voting from a mobile phone. We propose that the KOA system should be
used as an experimental platform for research in electronic and internet voting;
we are not saying that we have solved any of the major problems inherent in
voting with computers.
1
Introduction
The Netherlands is known for its forward-thinking and progressive government, laws,
and policies. Unfortunately, a government’s progressiveness, particularly with respect
to the adoption of new technology, is sometimes contrary to the good of its citizens.
Accordingly, in order to help avoid such a situation in the adoption of remote voting
technology in the Netherlands, the Security of Systems (SoS) Group at Radboud University Nijmegen became directly involved in the evaluation and development of the
KOA system in 2004.
4
“Kiezen op Afstand” is literally translated from Dutch as “Remote Voting.”
1.1
Voting Machines in the Netherlands
The introduction of such a system was not as radical a development as it might be
considered elsewhere. Electronic voting machines (EVMs) were introduced without
controversy in the Netherlands around 1998. They have been widely used in local and
national elections ever since. The primary supplier of these machines is Nedap5 , the
same supplier as in Ireland.
Part of the reason that EVMs were so readily accepted is historical. The Netherlands has used digital voting machines6 since the 1980s. Therefore, Dutch citizens are
comfortable with the idea of using technology for voting. The security and reliability
issues of the new generation of machines was not a serious problem at the time of their
introduction, much like their adoption by other governments in the late 1990s.
Unfortunately, many aspects of these systems have not been made public, contrary
to the requests of concerned parties in the Netherlands. The internals of such systems
are secret and are only exposed to evaluators. Each system must be examined, according
to an unknown set of criteria, before being accepted by the Dutch parliament for use in
elections. Evaluation reports compiled by the national reviewer, TNO7 , are also secret.
However, as attention has been focused the world over on EVMs, the Dutch parliament has begun to re-evaluate its approach. Changes to the current systems are likely to
be mandated soon, particularly with respect to voter verifiable paper trails.
In keeping with this reassessment, the Dutch parliament decided to conduct experiments with the next natural step in the use of technology for voting: remote voting using
both the internet and telephone. The main inspiration is that, nowadays, many personal
transactions (e.g., banking), can be carried out from arbitrary locations, so why not
voting?
Indeed, it is believed by some that a remote voting system will increase electoral
participation by making the process more convenient. Currently, Dutch citizens must
find time during the extended business hours (08:00 to 20:00) of a single day of the
working week. Furthermore, each individual must vote in a particular location near
their home, which may be far from their workplace.
However, given what we know about the unreliability and vulnerability of software
and networks, do the risks inherent in the introduction of such a system outweigh such
benefits?
These risks, together with the methods adopted in eliminating and minimising them
in the KOA system form the basis for the rest of this paper. It is organised as follows.
Section 2 presents some background information on the genesis of the KOA project.
Past academic work on the system up to the end of 2005 is presented in Section 3. A
security assessment of the KOA system is put forward in Section 4. Current work is
discussed in Section 5. Related work is compared and contrasted in Section 6. Future
work is considered in Section 7 and Section 8 concludes.
5
6
7
Nedap - http://www.nedap.com/.
The previous-generation systems with little-to-no software.
TNO - Netherlands Organisation for Applied Scientific Research http://www.tpd.tno.nl/tno/index.xml.
2
Kiezen op Afstand (KOA)
The genesis of KOA stemmed from a promise made by the Dutch government to parliament that they would investigate possible developments to the Dutch voting system.
This promise was fulfilled in the KOA experiment by allowing expatriates to vote in the
elections to the European Parliament via the internet and by telephone.
However, Dutch national election law is quite explicit about what is permitted with
respect to how votes may be cast. Therefore, in order to conduct an experiment in voting
over the internet, some amendments to this general law were formulated. This formed
the legal foundation for the KOA project.
Apart from the general rules governing internet voting, it also included some additional rules detailing a citizen’s right to vote from a different polling booth other than
the one originally appointed. However, in this paper we will refer to the KOA project
as if it consisted purely as an internet voting experiment.
2.1
Internet Voting in the Netherlands
The elections to the European Parliament of June 2004 allowed remote voting via the
internet and telephone. It was limited to expatriates who were required to explicitly
register beforehand. It was thought that such a small-scale use (thousands of voters)
would provide a useful real-world test for the technology.
The main reason why it was thought that an internet-based solution was suitable
is decidedly non-technical. Essentially, by significantly constraining the remote voting
problem, particularly with respect to the registration and voting process itself, it was
believed that a “sufficiently secure” and reliable system could be constructed. In particular, the system needed to be at least as secure and reliable as the existing remote voting
system which was based upon postal ballots.
The Remote Voting Process When a citizen registers to use KOA, the voter chooses
their own personal access code (a PIN). Some time later, a customised information
packet is mailed to the voter. This packet contains general information about the vote
itself (date, time, etc.), as well as voter-customised details that are known to only that
voter. These details include information for voter authentication, including an identification code and the previously chosen access code.
Also included is a list of all candidates. Each candidate is assigned a large set of
unique random numbers8 , and exactly one of those numbers is given to each voter. The
set of codes per voter is determined randomly but is not unique.
To vote, a registered voter logs in to a web site with their voter code and access
code. They then step through a series of simple web pages, typing in their candidate
codes as appropriate for their choices. The system shows the voter the actual names and
parties of the candidates in question to confirm the accuracy of the vote. When a voter
is finished, a transaction code is provided. This code can later be used to check in a
published list that the voter’s choices were included correctly in the final tally.
8
1,000 codes were generated for each candidate for the elections to the European Parliament in
2004.
Communication with the voting web site is secured with SSL. All votes are stored
in a doubly-encrypted fashion; each vote is encrypted by a symmetric key per voter9
and the public key of the voting authority.
2.2
Use and GPL Release
The trial during the elections to the European Parliament in June, 2004 was restricted to
roughly 16,000 eligible Dutch expatriates. Expatriates could vote either via the internet
or by telephone. The telephone votes were fed into the KOA tally system. 5,351 people
used one or other system.
Subsequently, in July 2004, the Dutch Government released the majority of the
source code for the KOA system under the GNU General Public Licence (GPL) making
it the first Open Source internet voting system in the world.
3
Academic Past Work
3.1
External Security Evalution
In late 2003 Prof. Bart Jacobs of the Security of Systems (SoS) group at Radboud
University Nijmegen participated in an external review of the requirements and design
of this application. One of the recommendations made by the panel was that the system
should not be designed, implemented and tested all by the same company.
The system itself was designed and implemented by LogicaCMG10 . Although eventually the government decided to make the system open source, during implementation
it was not. In order to improve its quality, the Dutch company Software Improvement
Group11 performed a code review of the system. However, they were only allowed to
do so after signing Non-Disclosure Agreements (NDAs). In fact, it was unexpected that
the government ultimately opted for an Open Source solution.
The SoS group did not take part in the design or implementation of the system.
However, the group took an active part in the final stages of the project. The group
performed two tasks: it wrote an independent tally application which will be explained
in detail in Section 3.2 and it performed a penetration test on the vote servers.
The penetration test was set up as a black box test. In particular the SoS group had
virtually no knowledge regarding the actual hardware, software, networks or personnel
involved with the server system. Indeed, the information it did possess could have been
considered public information since it could easily be obtained by standard available
analysis tools.
The main goal was to break into the system and try to compromise its integrity. The
second goal was to test whether the system was vulnerable to denial of service attacks.
Two evaluations were conducted. The first was unsolicited and took place during a
private beta test of the system. The second was requested by the government, primarily
because of the results of the first evaluation.
9
10
11
This symmetric key is generated by hashing the assigned identification code.
http://www.logicacmg.com/.
http://www.sig.nl.
During the first unsolicited evaluation the subnet running the service was gently
probed and mapped using nmap, a more detailed evaluation of specific machines was
then conducted, specifically with regards to machines running inappropriate services,
weaker operating systems, etc., and finally, on the last afternoon of the test, a denial-ofservice attack on the machines was conducted.
The main discovery of the first evaluation was that the system was not “tightened
down” insofar as test and management machines which were running insecure versions
of particular operating systems (e.g., Microsoft Windows) were on the deployed subnet,
no hardware or software firewall was in place on the system, machines has likely external exploits available, and nearly all systems had inappropriate services running (e.g.,
unused mail servers, databases, file sharing, etc.). Also, the SoS group was able to significantly harm their service quality with our (admittedly very small) denial-of-service
attack.
After the authorities realized the SoS group was responsible for this attack they
asked us for a report of our findings. Given the feedback and analysis, they then asked
the SoS group to perform an “official” external evaluation once they incorporated all of
our suggestions and tightened-down the network.
The second evaluation found that their systems were adequately hosted, monitored
and configured, their software was up-to-date, and no unnecessary services were running. Furthermore, adequate measures were in place for detecting basic probes by adversaries. Thus, in the end, the SoS group did not find any problem with the system
that would have caused the Dutch Ministry to reject it for an experimental run, and the
external evaluation significantly improved the security and reliability of the system.
3.2
Vote Counting System
As seen in the previous section, one of the results of the recommendation to split the
responsibilities of the parties involved, was that the government decided to accept bids
for the creation of a separate vote counting subsystem, to be implemented in isolation
by a third party. This separate tally application would allow the vote counting to be
independently verified. The SoS group put forward a proposal to write this application,
and were successful in this bid. The key idea behind their tender was that the vote
counting program should be formally verified using the JML [2] and ESC/Java212 [10]
tools.
The vote counting system formed a small but important part of the whole KOA
system. This provided the SoS group with a suitable opportunity to test the use of some
of the formal techniques and practices that they had been developing. Given the severe
time constraints placed upon them due to the impending election, the application was
built by three members of the group over a barely-sufficient period of four weeks. Java
was chosen as the programming language in which to implement the system so that
JML could be used as the formal specification language. Due to the time constraints,
verification was only attempted with the core modules.
12
ESC/Java2 is a programming tool that attempts to partially verify JML annotated Java programs by static analysis of the program code and its formal annotations. It translates the specifications into verification conditions that are modularly discharged by an automatic theorem
prover.
Counting votes within KOA proceeds offline using a separate tally application. The
input to this application consists of two XML files (one containing the list of candidates
and their codes, and one containing the encrypted votes), and a public/private keypair
used to decrypt the votes.
As the informal requirements of vote-counting are obvious (for every candidate in
the candidate list count the number of votes for that candidate), the functional specification [12] (in Dutch) mostly prescribes details of file formats and encryption algorithms
to be used.
Nevertheless, the functional specification does impose some requirements that greatly
influence the structure of the Java application and its JML specification. First, the different tasks that need to be performed in order to count the votes (reading in the two
files, reading in the keys, decrypting the contents of the votes file, counting the votes,
generating reports) are made explicit in this document and, more importantly, the order
in which they have to be performed is specified. Second, the document provides a rough
sketch of the user interface and its contents. Finally, the document gives some bounds
on the data, such as the lengths of fields or the maximum number of candidates in each
list, which are incorporated in the JML specifications of the data structures.
In accordance with the above high-level specification, the resulting tally application consists of some 30 classes, which can be grouped into three categories: the data
structures, the user interface, and the tasks.
The data structure classes form an excellent opportunity to write JML specifications. Typical concepts from the domain of voting, such as candidate, district and municipality can be modeled with detailed JML specifications. An example invariant in
Candidate.java is:
/*@ invariant my_gender == MALE ||
@
my_gender == FEMALE ||
@
my_gender == UNKNOWN;
*/
The different tasks associated with counting votes were mapped to individual classes.
After successful completion of a task, the application state is changed. A task can only
be started if the application is in an appropriate state. The life-cycle model of the application that therefore emerges is maintained in the main class of the application inside
a simple integral field. This life-cycle model can be specified in JML using invariants
and constraints, essentially stating that on successful completion of the application, the
application went from “initial state” to “votes counted state”. The state of attributes associated with the individual tasks can be linked to the application life-cycle state using
invariants. For instance, such an invariant could read: ‘after the application reaches the
“keys imported state”, the private key field is no longer null’. This is stated in MenuPanel.java as follows:
/*@ invariant
@
(state >= PRIVATE_KEY_IMPORTED_STATE
@
==> privateKey != null);
/
*
A graphical user interface is usually not very amenable to formal specification.
Nonetheless, some light-weight specifications were written. One of the requirements
defined in the original informal specification was that users should not be allowed to
start certain tasks before certain other tasks are successfully completed. For instance,
a user should (by means of the user interface) not be able to start decrypting votes
before the votes are read in from file. In the graphical user interface, this demand is
met by only enabling certain buttons when the application reaches certain states in the
life-cycle model. The fact that the graphical user interface complies with the life-cycle
model can be neatly specified in the GUI classes by referring to the application state.
3.3
Process
As already stated, ESC/Java2 was only used to verify the core of the tally application.
This means that it was used to verify reading in the XML-files with the candidates and
the votes, decryption of the votes and counting the votes. The final generation of the
reports is not checked with JML.
Using JML on reading XML files is quite straightforward. Essentially, for every object that is read, some methods are called that specify that the total number of objects
will be increased by exactly one. Naturally, in order to verify code that uses functionality provided in external libraries, some of the corresponding APIs must also be specified. The JML community has provided specifications for most of the APIs that come
with Sun’s standard edition of Java. However, APIs dealing with cryptography, XML
parsing, and PDF generation, as used by the tally application had not previously been
specified. These APIs were specified in a light-weight manner: the specifications mostly
deal with purity and non-null references in the API methods which makes verification
of client code using ESC/Java2 much easier.
Naturally, the counting process is likewise formally specified in JML, which ensures that each valid vote is counted for exactly one candidate. This also implies that
specifications are easy to check to make sure that the total number of votes a party list
receives is equal to the sum of votes for each candidate13 on this party list.
The JML run-time assertion checker was also used in the development process.
First, for testing the data structure classes, the checker was used to generate unit tests.
Second, we ran the full application, including user interface, using the checker.
3.4
Analysis of KOA
In the Dependable Software Research Group at Concordia University, the KOA source
code was used as a subject of a study in the frequency of occurrences of non-null reference type declarations [3]. This work consisted in adding nullity annotations (or constraints) and then verifying their correctness by making use of ESC/Java2. The results
were similar to those of Fähndrich and Leino [13], that is to say, it was found that even a
simple specification exercise of adding nullity annotations can help uncover non-trivial
bugs both in the code and in the specifications.
13
Including the ‘blanco’ or ‘blank ballot’ candidate.
For example, in the sos.koa.CounterAdapter class in the Tally Application
it was found that the field named errors is declared nullable and yet the method
getErrors, which uses this field, assumes that the field is non-null (i.e., a
NullPointerException will not be thrown).
3.5
Reverse Engineering Missing Components
The version of KOA released under the GPL was not complete. A number of pieces of
functionality, constituting roughly 10% of the deployed KOA system, were proprietary
and owned by LogicaCMG. Moreover, certain other changes were made for publication
purposes (e.g., the length of public/private key pairs in the source code).
In addition, the released KOA system contains no high-level design documentation
and very little information on how to build the system. This means that it is only possible
to inspect the (partial) source, not to compile and run it. Therefore, it was necessary to
perform a full analysis of the released system [14].
One of the most beneficial aspects of this analysis was that errors were found in
the KOA system. One such error was found in the Java Server Pages (JSPs) whereby a
button that should have guided the user back to the interface homepage had, in fact, the
same action as that of the “submit” button that processed and saved a list of candidates to
the database. This was due to a trivial mistake: placing the HTML tags for the “Return
Home” button within the FORM tag block. This error was discovered during a trivial
“click through” of the user interface followed by an examination of the code.
Such a basic mistake in the design of the user interface of a critical system is unacceptable. The fact that such a mistake could be made, remain unnoticed in the testing
and evaluation phase of the software, and actually be used in the elections to the European Parliament, would suggest that there is in all likelihood further errors in this
software.
Once the analysis was complete, the missing functionality was reverse engineered.
59 additional classes, together with some properties files, were added to the system.
These classes carry out the base functionality of the servlets, error reporting, logging
functionality, event handling, etc.
3.6
Full Open Source Foundations
One of the major goals in the redevelopment of the KOA system was that it would be
entirely composed of, and dependent upon, Open Source software. The original system
was developed in, deployed upon and tightly coupled to the IBM WebSphere IDE. During the reimplementation, the KOA system was ported to an Open Source alternative.
This foundation consisted of a MySQL database server backend, twinned with a JBoss
application server front-end which incorporated the Tomcat servlet container. The other
major restriction in terms of making the system fully GPL-compliant was its use of
proprietary security and encryption utilities developed by IAIK and Sun. These were
seamlessly replaced using the BouncyCastle Open Source alternatives.
3.7
Formal Specification and Extended Static Checking Review
As has already been stated, the Vote Counting Application of the KOA system was
specified with formal methods, extensively tested and partially verified to the extent that
was possible within the given timeframe. Subsequently, efforts were made to complete
the specification and verification [8].
When the KOA vote counting system was being designed, precedence was given
to verifying the core units. These were designed by contract and as result have good
specification coverage. The remaining parts, however, were only lightly annotated with
JML notation.
Classes
Methods
NCSS
Specs
Specs:NCSS
File I/O
8
154
837
446
1:2
Graphical I/O
13
200
1599
172
1:10
Core
6
83
395
529
5:4
Table 1. KOA initial release system summary
Table 1 summarizes the size (in number of classes and methods), complexity (noncomment size of source (NCSS)), and specification coverage of the three subsystems,
as measured with the JavaNCSS tool version 20.40 during the week of 24 May, 2004.
This is the version of the program that was released and used in the elections to the
European Parliament in June 2004.
At the time of its initial release, verification coverage of the core subsystem was
good, but not 100%. Approximately 10% of the core methods (8 methods) were unverified due to issues with ESC/Java’s Simplify theorem prover (i.e., either the prover did
not terminate or terminated abnormally). Another 31% of the core methods (26 methods) had postconditions that could not be verified, typically due to completeness issues
in ESC/Java, and 12% of the methods (10 methods) failed to verify due to invariant
issues, most of which are due to suspected inconsistencies in the specifications of the
core Java class libraries or JML model classes. The remaining 47% (39 methods) of the
core verified completely. Since 100% verification coverage was not possible in the timeframe of the original project, to ensure the KOA application was of the highest quality
level possible, a large number unit tests were generated14 for all core classes with the
jmlunit [4] tool, which is part of the JML suite. A total of nearly 8,000 unit tests were
generated, focusing on key values of the various datatypes and their dependent base
types. These tests cover 100% of the core code and are 100% successful.
14
The tool generates unit tests that deal with interesting values. Interesting values are generally
boundary values for a given data type. For example, -1, 0, 1, n and n+1 for an array of integers.
Users are also free to handwrite their own test cases, in the case where the jmlunit tool does
not test all important values.
After this analysis was completed, the specifications were gradually augmented. As
an example, consider the AuditLog class. This class records information about the
vote counting as the application proceeds. This information is then used at the end of
the vote counting to help fill in the details for two of the reports that are generated.
This class keeps track of the program’s progress in a similar manner to that which
was used for the overall program state. There were multiple invariants used to ensure
the program and auditing proceeded in the correct fashion. Several corrections were
required for this class, the bulk of which were modifications to the behaviours of the
methods that allowed the audit log’s state to change. The original specifications allowed
the possibility that the variables could be changed to a state where the invariants would
not hold. The changes made to this class’ specifications disallowed any actions that
would violate the object invariants.
3.8
Documentation Writing and Translation
The vast majority of the voting system, including high-level documentation, web interfaces, Java comments and variable names are in Dutch. Furthermore, much of the
voting system is sparsely commented and unspecified. This clearly poses an obstacle to
the understanding and adoption of such a system by a wider, international audience. It
was therefore decided at an early stage that a complete translation of the system into
an international language such as English, together with the production of additional
documentation, was necessary in order to facilitate a larger number of people to carry
out the necessary specification, development and testing. Consequently, the major highlevel specification document and all of the JSPs have been translated from Dutch into
English.
3.9
Other Voting Systems
Naturally, there are relatively considerable variations in electoral systems between countries. This is the case between the Netherlands and Ireland. Not only are these differences linguistic, but more significantly there are different vote counting procedures in
the Netherlands and in Ireland. The Dutch Voting system is list based while Ireland uses
Proportional Representation with a Single Transferable Vote (PR-STV).
The Irish Voting System The Dáil, Ireland’s lower house of parliament, is composed of 166 members representing 41 constituencies. Each constituency elects multiple members to parliament. The average constituency elects four representatives with
every constituency electing at least three representatives. The system used is PR-STV.
This combination is considered to increase the representativeness of the Dáil.
Irish voters, by ranking the candidates, give instructions as to who should receive
their support should the first choice candidate be eliminated or elected. Surplus votes
are the number of votes in excess of the threshold of election a candidate receives.
Surplus votes are transferred proportionally to the remaining candidates according to
the indicated second preference of the voters. If the election is undecided after counting
the first preferences and transferring surplus votes, then the lowest polling candidate
is eliminated. The ballots cast initially in support of this candidate are now counted
according to their indicated second preference. If any candidate has more than a quota
of votes then he or she is elected and his or her surplus votes are transferred to the next
preference candidate. If there are more candidates than seats and all surpluses have been
transfered, then the candidate with least votes is excluded and his or her votes transfered
to the next preference on each ballot paper. This process is repeated until the number of
candidates remaining equals the number of seats remaining.
Formal Specification Votáil is the Irish word for voting. The Votáil specification is
a JML specification for the Irish vote counting system [5]. This formal specification
is derived from the complete functional specification for the Dáil election count algorithm [6,7].
Thirty nine formal assertions were identified in the Commentary on Count Rules
published by the Irish Department of Environment and Local Government. Each assertion expressed in JML was identified by a Javadoc comment. In addition, a state
machine was specified so as to link all of the assertions together. Java classes were
specified for the vote counting algorithm, to represent the ballot papers and candidates.
A concrete example of how the methodology was applied will clarify this work.
Section 7, item 3.2 on page 25 of [6] states:
As a first step, a transfer factor is calculated, viz. the number of votes in the
surplus is divided by the total number of transferable votes in the last set of
votes. This transfer factor is multiplied in turn by the total number of votes in
each sub-set of next available preferences for continuing candidates (note that
the transfer factor is not applied to the sub-set of non-transferable votes in the
set of votes).
The requirement is translated into formal natural language as follows:
The number of votes in the surplus is divided by the total number of transferable votes in the last set of votes. This transfer factor is multiplied in turn
by the total number of votes in each sub-set of next available preferences for
continuing candidates.
Finally, this formal natural language is formally specified in the architecture as a
JML postcondition for the method that is specifically for this requirement (the
getActualTransfers method). The Javadoc and JML specification for this method
follows.
/**
* Determine actual number of votes to transfer to
* this candidate, excluding rounding up of
* fractional transfers
*
* @see requirement 25 from section 7 item 3.2
* on page 25
*
* @design The votes in a surplus are transfered in
* proportion to the number of transfers available
* throughout the candidates ballot stack. The
* calculations are made using integer values
* because there is no concept of fractional votes
* or fractional transfer of votes, in the existing
* manual counting system. If not all transferable
* votes are accounted for the highest remainders
* for each continuing candidate need to be examined.
*
* @param fromCandidate Candidate from which to
count the transfers
*
* @param toCandidate Continuing candidate eligible
to receive votes
*
* @return Number of votes to be transfered,
excluding fractional transfers
*
*/
//@ ensures
//@ \result ==
//@
(getSurplus(fromCandidate) *
//@
getPotentialTransfers(fromCandidate,
//@
toCandidate.getCandidateID()) /
//@
getTotalTransferableVotes(fromCandidate);
The Votáil specification was typechecked and checked for soundness using ESC/Java215 .
4
Security Assessment
Issues of security and correctness are paramount in any voting system. This is especially
the case for a remote internet voting system due to the inherent vulnerabilities of the
architecture. Any such system must be as secure as the system it is designed to replace.
Otherwise, trust in the electoral and democratic systems of a country can be severely
damaged.
The KOA system was designed to replace absentee postal ballots. It has always been
accepted that postal voting is not as secure as voting in a polling booth. KOA follows all
of the standard security mechanisms and also introduces some novel approaches. These
security mechanisms are focused on attack prevention and, where this is impossible, on
detection of intrusion. This section discusses these security mechanisms.
4.1
Data Integrity
The most significant method used in the KOA system to ensure data integrity is the
use of candidate codes. 1,000 codes are generated for each candidate and only one of
these is randomly assigned to each voter. Therefore, even if a malicious agent (e.g., a
15
The soundness of the JML specifications is checked using an alpha extension to ESC/Java2
which manipulates the JML abstract syntax tree in order to determine whether certain combinations in preconditions and postconditions are inherently unsatisfiable.
worm, virus or Trojan horse) can access a ballot, all the attacker can see are the encoded
candidate and party IDs, which in the optimal case are unique to the voter in question.
Consequently, it will be virtually impossible to substitute the ballot by choosing the
appropriate code for a different candidate.
In addition, the votes are doubly-encrypted. The only way to decrypt these votes on
the server side is to close the polls. Closing the polls is an irreversible action. Consequently, altering the votes at the server-side is precluded.
In the case where the voter tries to cast multiple votes at once (e.g., via both telephone and internet) there will always be one first vote. This vote will be stored. The
second attempt will fail because the voter has already cast his/her vote.
Finally, the KOA system has the capability to take snapshots of the candidate and
voter lists called “electronic fingerprints.” These fingerprints can be generated at any
time to ensure that these lists have not been maliciously altered. One possible extension
to the system is to automate the generation of these fingerprints at regular intervals to
ensure a regular verification of data integrity.
4.2
Verifiability
Voters using the KOA system are able to verify that their vote is recorded correctly and
is included in the final tally of the election using the transaction code they receive upon
casting their ballot. This is possible due to the publication of a list of the transaction
codes of votes for each candidate after the election. Such a check can identify any
compromised PCs and in the worst case invalidate the election.
4.3
Insider Threats
The power to change the state of the system and to decrypt the votes is restricted to a
small number of polling station officials. These officials hold the private key for the system and each has a PIN code to use this private key. One of these officials is designated
as the current “president” or “chairman.”
In order to change the state of the system (e.g., open/close the polls, decrypt the
votes, etc.), the chairman and one other official must enter their PIN codes. If the role
of chairman is alternated at set time intervals among random officials (or some similar
mechanism), then all officials need to be in collusion in order to tamper with the system.
Even then, access to the decrypted ballots is precluded, as is mentioned in Section 4.1.
4.4
Other Security Features
A part from the use of SSL, there are a couple of further noteworthy security features.
Firstly, random data is added to the votes when they are encrypted. This ensures
that votes within the same voter district and for the same candidate have a different
encryption result for each vote, making it impossible to interpret encrypted votes.
Secondly, the votes are decrypted in a random order in order to making tracing
voters by the order in which they voted impossible.
4.5
Problems
Despite the best efforts to make KOA as secure as possible, certain security flaws still
remain. These need to be addressed before further use of the system.
Firstly, if the electronic fingerprints of the system are not identical at a particular
point in time, the chairman can overrule and allow the election to continue. This should
not be permitted.
Like other forms of remote voting (e.g., postal voting), KOA does not provide protection for voter anonymity in the case where another person is in the vicinity of the
voter during the voting process or if another person gains access to a voter’s transaction
code. However, due to the use of candidate codes, excluding these two scenarios, it is
virtually impossible to connect a voter to his/her vote.
Denial of Service Attacks (DoS) As has already been stated in Section 3.1, the KOA
system is vulnerable to DoS Attacks. This is practically impossible to prevent and is a
feature of all remote internet voting systems.
One feature of the KOA system that lessens some of the problems caused by DoS
attacks is that the system can be interrupted. When this state change happens, an electronic fingerprint of all the system data is taken and this can be checked against a subsequent fingerprint on system resumption. Clearly, this does not solve the problem of
potential temporary disenfranchisment, but it does ensure data integrity in the face of a
such an attack.
4.6
Summary
As has been described, all of the standard security mechanisms have been used together
with some innovative techniques to ensure data integrity and verifiability. However,
obviously the issue of security is one of the open questions of remote internet voting
and there are a number of problems yet to be overcome. We believe these problems can
be addressed by research and experimentation on a verified open source framework,
like the one which KOA aims to provide.
5
5.1
Academic Current Work
Generalisation of System for non-Dutch Voting Systems
The Java code for Votáil was written in JML using a kind of “verification-centric” Design by Contract methodology. This means that not only are we writing each method
implementation according to its JML specification, but we are checking each method’s
correctness with ESC/Java2 and automatically generating thousands of unit tests using
JML-JUnit [4].
The KOA system has a state machine similar to that used in the Votáil specification. This allows KOA to make calls to the appropriate part of the Votáil code. The
ElectionAlgorithm class in Votáil will be invoked from within the KOA system
using the following four method calls: setup, which defines election parameters such
as candidate list and number of seats, load, which loads all valid ballots and then calculate quota and deposit saving thresholds, count, which assign votes to candidates,
distribute surpluses and exclude candidates until finished, and report, which reports
the election results. These methods must be called in the order shown, and this fact
is captured by the invariants of the state machine. Only the report method is called
more than once for each instance of the ElectionAlgorithm class.
The user interface is being designed in a flexible fashion so as to present non-Dutch
ballot papers to the voter. The original KOA system was designed for use with a partylist system with a single national constituency. Its user interface is being extended in
line with the guidelines for the Irish voting system. The KOA system allows the voter
to select a list of candidates. In the Irish system each candidate is in a list of size one.
The KOA system allows only one selection by the voter. In the Irish system the voter
makes multiple selections in order of preference.
6
Related Work
6.1
A Security Analysis of SERVE
The security analysis of the SERVE project [9] is one of the best known examinations
of remote internet voting. It is very critical of current efforts and advises against any use
of such methods given the current state of technology, due to its inherent vulnerabilities.
Two main arguments against internet voting can be distinguished in the report.
Firstly, it is argued that the system allows for vote buying and selling. However, this
holds for any voting system in which voters vote at home. Internet voting can only be
fairly compared to postal ballots, not to voting at polling stations. If we want to introduce remote voting on a large scale, measures can be taken (technical, organisational,
and legal) that make it unattractive to buy or sell votes.
A second argument against internet voting is that the technology is vulnerable to
attacks. Unfortunately, despite claiming to have examined alternatives to the SERVE
system, it ignores systems that have overcome some, but not all, of the problems mentioned. Although, the KOA system was not fully developed at the time of writing, the
recommendations presented in 2002 by Dr. Rolf Oppliger16 for the use of a remote internet voting system in Geneva17 , describe security mechanisms, such as code sheets,
that the authors of the SERVE report do not mention.
KOA is a much more secure system than SERVE in that it uses code lists for data
integrity, transaction codes for verifiability and is not closed and proprietary.
6.2
The RIES System
The RIES system was developed for elections for public water management authorities
in the Netherlands. It has two main features which create confidence in the limited
possibilities of attacking the system. First of all, a reference table is published before
16
17
How to Address the Secure Platform Problem for Remote Internet Voting in Geneva - available
from http://www.ifi.unizh.ch/∼oppliger/Docs/sis 2002.pdf
http://www.geneve.ch/evoting/english/welcome.asp
the elections, including (anonymously) for each voter the hashes of all possible votes,
linking those to the candidates. It is possible to compare the number of voters in this
table with the number of registered voters. After the elections, a document with all
received votes is published. This allows for two important verifications:
1. A voter can verify his/her own vote, including the correspondence to the chosen
candidate
2. Anyone can do an independent calculation of the result of the elections, based on
this document and the reference table published before the elections
If your vote has been registered incorrectly, or not at all, it can be detected. And
if the result is incorrect given the received votes, this can also be detected. The main
technique that achieves this is the clever use of hash functions. Whereas the hashes of
all possible votes are public, it is impossible to deduce valid votes from them without
the required voter key. Of course, the relation between voter and voter key should not
be stored anywhere, as is the case for bank access codes. The system has worked well
in an actual election with 70,000 voters.
A disadvantage of the RIES system in comparison with the KOA system is that a
voter needs to compute hash values in order to verify that a vote has been correctly
recorded. This is far more complicated than simply checking a transaction code in the
list of votes after the election.
7
Future Work
Several pieces of future work have been identified and some of them are currently underway by researchers at UCD.
7.1
Development of a Mobile E-Voting Application
The EU MOBIUS Project18 , of which UCD and Nijmegen are both members, focuses
on several topics including the specification and verification of security properties at
several levels.
As part of this work, the security properties, including a functional specification,
for a MIDP-based remote voting application are in the process of being defined. An example of such a security property is: “The application must not have access to personal
information (e.g., phonebook) on the mobile phone”.
Additionally, a MIDP-based remote voting applet has been developed at UCD. This
application has been reviewed and will be refactored, including the security and functional requirements expressed in JML, for incorporation into KOA.
7.2
Full-blown Verification
We intend to fully specify and verify critical subsystems of the KOA system as a case
study for the new MOBIUS Integrated Verification Environment (IVE) that is being developed by UCD and others. This goal is much more ambitious than simply performing
extended static checking on various critical classes.
18
The MOBIUS Project - http://mobius.inria.fr/
7.3
Just-in-Time Deployment with PCC
One of the primary problems with electronic voting systems is that new software updates, at both operating system and application levels, are typically installed in the field
without any certification [11]. One technology that can help solve this deployment issue is Proof-Carrying Code (PCC) [1,15], the primary underlying formal foundation
and technology used by the MOBIUS IVE.
Using a PCC technology foundation, new system and application patches could
be just-in-time deployed to the thousands of voting machines used in an election with
complete assurance. Developing such a foundation is part of the MOBIUS project’s
mandate, so the KOA system may be used as a deployment case study in the coming
years.
7.4
American Voting System
The American voting system is the focus of an intense amount of discussion and work,
given the ongoing fiasco in electronic voting we have witnessed in the U.S. over the
past several years.
After integrating the Votáil Irish voting subsystem, we would be interested in collaborating to formally specify and verify a voting subsystem for use in American presidential and/or congressional elections using the same verification-centric methodology
we have followed thus far.
7.5
Electronic Voting Systems
An electoral-system independent, formally specified and verified remote voting system
can be used in an electronic voting system, as the latter is just a trivial, non-remote
version of the former. It is our intention to build and demonstrate such a system, incorporating a new formally specified and verified voter-verifiable paper trail subsystem.
7.6
Reflections Future Plans
Many of these plans are “just” a matter of good software engineering and thus can be
accomplished by undergraduate and postgraduate students as case studies, theses work,
etc. Others are much more difficult. In particular, attempting verification in any form
and incorporating PCC techniques into the system are quite difficult, time consuming,
and even require new research to be conducted. This work will take several years to
accomplish, and only if the number of individuals and groups working on and with the
system grows over time.
8
Conclusion
The availability of an American voting subsystem will make KOA the first generalpurpose, formally specified and verified remote and local voting system available in
the world, and furthermore it will be available under the GPL license. Furthermore, the
KOA system is being donated to the UK Grand Challenge Verified Code Repository as
a major case study for the application of formal methods to critical, large-scale software
development.
It is unclear how to compare such a system to the current commercial and Free/Libre/Open
Source Software (FLOSS) voting systems being proposed by others, given that none of
them, to our knowledge, even write formal specifications, let alone perform verification.
We hope that this work will encourage other similar projects to seriously consider the
use of lightweight formal methods in such critical systems development.
While integrating the Votáil subsystem into the KOA system, and prior to/during the
new full FLOSS foundation release of KOA, a number of new pieces of English documentation and functional specification must be written. Given that remote voting is a
key case study in verified computing, we hope that the availability of such documentation and specification will provide additional motivation for researchers and developers
to seriously consider using the KOA system as a foundation for Verified Verifiable Voting (VVV).
We propose that the KOA system should be used as an experimental platform for
research in electronic and internet voting; we are not saying that we have solved any
of the major problems inherent in voting with computers. We encourage researchers
interested in electronic and internet voting to contact us and join this effort.
9
Acknowledgements
This work is being supported by the European Project Mobius within the frame of IST
6th Framework, national grants from the Science Foundation Ireland and Enterprise
Ireland and by the Irish Research Council for Science, Engineering and Technology.
This paper reflects only the authors’ views and the Community is not liable for any use
that may be made of the information contained therein.
References
1. Elvira Albert, Puri Arenas, and Germán Puebla. An Incremental Approach to AbstractionCarrying Code. In Proceedings of the 13th International Conference on Logic for Programming Artificial Intelligence and Reasoning (LPAR’06), Lecture Notes in Computer Science.
Springer–Verlag, November 2006.
2. Lilian Burdy, Yoonsik Cheon, David Cok, Michael Ernst, Joe Kiniry, Gary T. Leavens,
K. Rustan M. Leino, and Erik Poll. An Overview of JML Tools and Applications. International Journal on Software Tools for Technology Transfer, Feb 2005.
3. Patrice Chalin and Frédéric Rioux. Non-null References by Default in the Java Modeling Language. In Proceedings of the Workshop on the Specification and Verification of
Component-Based Systems (SAVCBS 2005), September 2005.
4. Yoonsik Cheon and Gary T. Leavens. A Simple and Practical Approach to Unit Testing: The
JML and JUnit Way. In Boris Magnusson, editor, Proceedings of the 16th European Conference on Object-Oriented Programming (ECOOP 2002), volume 2374 of Lecture Notes in
Computer Science, pages 231–255. Springer–Verlag, Jun 2002.
5. Dermot Cochran. Secure Internet Voting in Ireland using the Open Source Kiezen op Afstand
(KOA) Remote Voting System. Master’s thesis, University College Dublin, March 2006.
6. Department of Environment and Local Government, Commission on Electronic Voting.
Count requirements and commentary on count rules, 23 June 2000.
7. Department of Environment and Local Government, Commission on Electronic Voting.
Count requirements and commentary on count rules, update no. 7: Available surpluses and
candidates with zero votes, 14 April 2002.
8. Fintan Fairmichael. Full Verification of the KOA Tally System. Final Year Undergraduate
Project Thesis, March 2005.
9. David Jefferson, Aviel D. Rubin, Barbara Simons, and David Wagner. Analyzing Internet
Voting Security. Communication of the ACM, 47(10):59–64, 2004.
10. Joseph R. Kiniry and David R. Cok. ESC/Java2: Uniting ESC/Java and JML: Progress
and issues in building and using ESC/Java2 and a report on a case study involving the use
of ESC/Java2 to verify portions of an Internet voting tally system. In Construction and
Analysis of Safe, Secure and Interoperable Smart Devices: International Workshop, CASSIS
2004, volume 3362 of Lecture Notes in Computer Science. Springer–Verlag, Jan 2005.
11. Jason Kitcat. Source availability and e-voting: an advocate recants. Communications of the
ACM, 47(10):65–67, 2004.
12. LogicaCMG. Kiezen op Afstand: Hertellen Stemmen. Functional specifications, 2004.
13. M. Fähndrich and K. Rustan M. Leino. Declaring and Checking Non-Null Types in an
Object-Oriented Language. In Proceedings of the 18th Annual ACM SIGPLAN Conference
on Object-Oriented Programing, Systems, Languages, and Applications (OOPSLA 2003),
pages 302–312, New York, NY, USA, 2003. ACM Press.
14. Alan E. Morkan. KOA Evaluation, Demonstration Installation and Implementation. Final
Year Undergraduate Project Thesis, March 2005.
15. George C. Necula. Proof-Carrying Code. In Proceedings of the 24th ACM SIGPLANSIGACT Symposium on Principles of Programming Languages (POPL 1997), pages 106–
119, New York, NY, USA, 1997. ACM Press.