OASIS, the XML interoperability consortium, formed the Election and
Voter Services Technical Committee in the spring of 2001 to develop standards for
election and voter services information using XML. The committee’s mission
statement is, in part, to:
“Develop a standard for the structured interchange among
hardware, software, and service providers who engage in any aspect of providing election
or voter services to public or private organizations...”
The objective is to introduce a uniform and reliable way to allow
systems involved in the election process to interact. The overall effort attempts to
address the challenges of developing a standard that is:
· Multinational:
Our aim is to have these standards adopted globally.
· Flexible:
Effective across the different voting regimes (e.g. proportional representation or 'first
past the post') and voting channels (e.g. Internet, SMS, postal or traditional paper
ballot).
· Multilingual:
Flexible enough to accommodate the various languages and dialects and vocabularies.
· Adaptable:
Resilient enough to support elections in both the private and public sectors.
· Secure: Able
to secure the relevant data and interfaces from any attempt at corruption, as appropriate
to the different requirements of varying election rules.
The primary deliverable of the committee is the Election Markup
Language (EML). This is a set of data and message definitions described as XML schemas.
At present EML includes specifications for:
· Candidate Nomination,
Response to Nomination and Approved Candidate Lists
· Referendum Options
Nomination, Response to Nomination and Approved Options Lists
· Voter Registration
information, including eligible voter lists
· Various
communications between voters and election officials, such as polling information,
election notices, etc.
· Ballot information
(races, contests, candidates, etc.)
· Voter
Authentication
· Vote Casting and Vote
Confirmation
· Election counts and
results
· Audit information
pertinent to some of the other defined data and interfaces
· EML is flexible
enough to be used for elections and referendums that are primarily paper-based or that
are fully e-enabled.
Overview of the Document
To help establish context for the specifics contained in the XML
schemas that make up EML, the committee also developed a generic election process model.
This model identifies the components and processes common to many elections and election
systems, and describes how EML can be used to standardize the information exchanged
between those components.
Section 2 outlines the business and technical needs the
committee is attempting to meet, the challenges and scope of the effort, and introduces
some of the key framing concepts and terminology used in the remainder of the
document.
Section 3 describes two complementary high-level process
models of an election exercise, based on the human and technical views of the processes
involved. It is intended to identify all the generic steps involved in the process and
highlight all the areas where data is to be exchanged. The discussions in this section
present details of how the messages and data formats detailed in the EML specifications
themselves can be used to achieve the goals of open interoperability between system
components.
Section 4 presents a discussion of the some of the common
security requirements faced in different election scenarios, a possible security model,
and the mechanisms that are available in the EML specifications to help address those
requirements. The scope of election security, integrity and audit included in these
interface descriptions and the related discussions are intended to cover security issues
pertinent only to the standardised interfaces and not to the internal security
requirements within the various components of election systems.
The security requirement for the election system design,
implementation or evaluation must be placed with the context of the vulnerabilities and
threats analysis of a particular election scenario. As such the references to security
within EML are not to be taken as comprehensive requirements for all election systems in
all election scenarios, nor as recommendations of sufficiency or approach when addressing
all the security aspects of election system design, implementation or evaluation.
Section 5 provides an overview of the approach that has been
taken to creating the XML schemas.
Section 6 provides information as to the location of the
descriptions of the schemas developed to date.
Appendices provide information on internet voting security
concerns, TimeStamp schema, W3C Digital Signature, Acknowledgements and a revision
history.
The key words “MUST”, “MUST NOT”,
“REQUIRED”, “SHALL”, “SHALL NOT”,
“SHOULD”, “SHOULD NOT”, “RECOMMENDED”,
“MAY”, and “OPTIONAL” in this document are to be interpreted as
described in [RFC2119].
[RFC2119]
S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, http://www.ietf.org/rfc/rfc2119.txt, IETF RFC
2119, March 1997.
xNAL
eXtensible Name and Address (xNAL) Specifications and Description Document (v2.0)
Customer Information Quality Technical Committee OASIS July 2002 http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ciq
UK’s APD
Address and Personal Details Fragment v1.1 Technology Policy Team, e-Government Unit,
Cabinet Office UK, 1 March 2002
http://www.govtalk.gov.uk/interoperability/draftschema_schema.asp?schemaid=92
XML
Extensible Markup Language (XML) 1.0 (Third Edition) Tim Bray et al, Worldwide Web
Consortium, 4 February 2004 http://www.w3.org/TR/REC-xml
XML-DSig
XML-Signature Syntax and Processing Donald Eastlake et al, Worldwide Web Consortium, 12
February 2002 http://www.w3.org/TR/xmldsig-core/
VoiceXML
Voice Extensible Markup Language (VoiceXML) Version 2.0 Scott McGlashan et al Worldwide
Web Consortium 16 March 2004 http://www.w3.org/TR/voicexml20
Voting is one of the most critical features in our democratic
process. In addition to providing for the orderly transfer of power, it also cements the
citizen’s trust and confidence in an organization or government when it operates
efficiently. In the past, changes in the election process have proceeded deliberately and
judiciously, often entailing lengthy debates over even the most minute detail. These
changes have been approached with caution because discrepancies with the election system
threaten the very principles that make our society democratic.
Times are changing. Society is becoming more and more web oriented
and citizens, used to the high degree of flexibility in the services provided by the
private sector and in the Internet in particular, are now beginning to set demanding
standards for the delivery of services by governments using modern electronic delivery
methods.
Internet voting is seen as a logical extension of Internet
applications in commerce and government and in the wake of the United States 2000 general
elections is among those solutions being seriously considered to replace older less
reliable election systems.
The implementation of electronic voting would allow increased access
to the voting process for millions of potential voters. Higher levels of voter
participation will lend greater legitimacy to the electoral process and should help to
reverse the trend towards voter apathy that is fast becoming a feature of many
democracies. However, it has to be recognized that the use of technology will not by
itself correct this trend. Greater engagement of voters throughout the whole democratic
process is also required.
However, it is recognized that more traditional voting methods will
exist for some time to come, so a means is needed to make these more efficient and
integrate them with electronic methods.
In the election industry today, there are a number of different
services vendors around the world, all integrating different levels of automation,
operating on different platforms and employing different architectures. With the global
focus on e-voting systems and initiatives, the need for a consistent, auditable,
automated election system has never been greater.
The introduction of open standards for election solutions is
intended to enable election officials around the world to build upon existing
infrastructure investments to evolve their systems as new technologies emerge. This will
simplify the election process in a way that was never possible before. Open election
standards will aim to instill confidence in the democratic process among citizens and
government leaders alike, particularly within emerging democracies where the responsible
implementation of the new technology is critical.
OASIS, the XML interoperability consortium, formed the Election and
Voter Services Technical Committee to standardize election and voter services information
using XML. The committee is focused on delivering a reliable, accurate and trusted
XML specification (Election Markup Language (EML)) for the structured interchange of data
among hardware, software and service vendors who provide election systems and
services.
EML is the first XML specification of its kind. When implemented, it
can provide a uniform, secure and verifiable way to allow e-voting systems to interact as
new global election processes evolve and are adopted.
The Committee’s mission statement is:
“Develop a standard for the structured interchange of data
among hardware, software, and service providers who engage in any aspect of providing
election or voter services to public or private organizations. The services performed for
such elections include but are not limited to voter role/membership maintenance (new
voter registration, membership and dues collection, change of address tracking, etc.),
citizen/membership credentialing, redistricting, requests for absentee/expatriate
ballots, election calendaring, logistics management (polling place management), election
notification, ballot delivery and tabulation, election results reporting and
demographics.”
The primary function of an electronic voting system is to capture
voter preferences reliably and report them accurately. Capture is a function that occurs
between ’a voter‘ (individual person) and ’an e-voting system‘
(machine). It is critical that any election system be able to prove that a voter’s
choice is captured correctly and anonymously, and that the vote is not subject to
tampering.
Dr. Michael Ian Shamos, a PhD Researcher who worked on 50 different
voting systems since 1980 and reviewed the election statutes in half the US states,
summarized a list of fundamental requirements, or ’six commandments’, for
electronic voting systems:
· Keep each
voter’s choice an inviolable secret.
· Allow each eligible
voter to vote only once, and only for those offices for which he/she is authorized to
cast a vote.
· Do not permit
tampering with voting system, nor the exchange of gold for votes.
· Report all votes
accurately
· The voting system
shall remain operable throughout each election.
· Keep an audit trail
to detect any breach of [2] and [4] but without violating [1].
In addition to these business and technical requirements, the
committee was faced with the additional challenges of specifying a requirement that
was:
· Multinational –
our aim is to have these standards adopted globally
· Effective across the
different voting regimes – for example, proportional representation or ‘first
past the post’, preferential voting, additional member system
· Multilingual –
our standards will need to be flexible enough to accommodate the various languages and
dialects and vocabularies
· Adaptable – our
aim is to provide a specification that is resilient enough to support elections in both
the private and public sectors
· Secure – the
standards must provide security that protects election data and detects any attempt to
corrupt it.
The Committee followed these guidelines and operated under the
general premise that any data exchange standards must be evaluated with constant
reference to the public trust.
The goal of the committee is to develop an Election Markup Language
(EML). This is a set of data and message definitions described as a set of XML schemas
and covering a wide range of transactions that occur during an election. To achieve this,
the committee decided that it required a common terminology and definition of election
processes that could be understood internationally. The committee therefore started by
defining the generic election process models described here.
These processes are illustrative, covering the vast majority of
election types and forming a basis for defining the Election Markup Language itself. EML
has been designed such that elections that do not follow this process model should still
be able to use EML as a basis for the exchange of election-related messages.
EML is focussed on defining open, secure, standardised and
interoperable interfaces between components of election systems. Thus providing
transparent and secure interfaces between various parts of an election system. The scope
of election security, integrity and audit included in these interface descriptions and
the related discussions are intended to cover security issues pertinent only to the
standardised interfaces and not to the internal or external security requirements of the
various components of election systems.
The security requirement for the election system design,
implementation or evaluation must be placed within the context of the vulnerabilities and
threats analysis of a particular election scenario. As such the references to security
within EML are not to be taken as comprehensive requirements for all election systems in
all election scenarios, nor as recommendations of sufficiency of approach when addressing
all the security aspects of election system design, implementation or evaluation. In
fact, the data security mechanisms described in this document are all optional, enabling
compliance with EML without regard for system security at all. A complementary
document may be defined for a specific election scenario, which refines the security
issues defined in this document.
EML is meant to assist and enable the election process and does not
require any changes to traditional methods of conducting elections. The extensibility of
EML makes it possible to adjust to various e-democracy processes without affecting the
process, as it simply enables the exchange of data between the various election processes
in a standardized way.
The solution outlined in this document is non-proprietary and will
work as a template for any election scenario using electronic systems for all or part of
the process. The objective is to introduce a uniform and reliable way to allow election
systems to interact with each other. The proposed standard is intended to reinforce
public confidence in the election process and to facilitate the job of democracy builders
by introducing guidelines for the selection or evaluation of future election systems.
Figure 1A: Relationship overview
To meet our objectives, the committee has defined a process model
that reflects the generic processes for running elections in a number of different
international jurisdictions. The processes are illustrative, covering a large number of
election types and scenarios.
The next step was then to isolate all the individual data items that
are required to make each of these processes function. From this point, our approach has
been to use EML as a simple and standard way of exchanging this data across different
electronic platforms. Elections that do not follow the process model can still use EML as
a basis for the exchange of election-related messages at interface points that are more
appropriate to their specific election processes.
The EML specification is being used in a number of pilots to test
it’s effectiveness across a number of different international jurisdictions. The
committee document set will include:
· Voting
Processes: A general and global study of the electoral process. This introduces the
transition from a complete human process by defining the data structure to be exchanged
and where they are needed.
· Data
Requirements: A data dictionary defining the data used in the processes and required
to be handled by the XML schemas.
· EML
Specifications: This consists of a library of XML schemas used in EML. The XML
schemas define the formal structures of the election data that needs to be exchanged.
· Report on
Alternative methods of EML Localisation: EML provides a set of constraints common to
most types of elections worldwide. Each specific election type will require additional
constraints, for example, to enforce the use of a seal or to ensure that a cast vote is
anonymous. This document describes alternative mechanisms for expressing these
constraints and recommends the use of schemas using the Schematron language to supplement
the EML schemas for this purpose.
To conform to this specification, a system must implement all parts
of this specification that are relevant to the interfaces for which conformance is
claimed. The required schema set will normally be part of the purchasing criteria and
should indicate schema version numbers. For example, in the future, the specification for
an election list system might specify that a conforming system must accept and generate
XML messages conforming to the following schemas:
|
Schema
|
Accept
|
Generate
|
|
EML110
|
V5.0, V4.0
|
|
|
EML310
|
V5.0, V4.0
|
|
|
EML330
|
|
V5.0
|
|
EML340
|
|
V5.0
|
|
EML350
|
|
V5.0
|
|
EML360
|
|
V5.0
|
A conforming system will then conform to the relevant parts of this
specification and the accompanying schemas.
At the outset of our work, it was clear that the committee would
need to rationalize the different terms that are commonly used to describe the election
process.
Terms used to describe the election process, such as ballot and
candidate, carry different meanings in different countries – even those speaking
the same language. In order to develop a universal standard, it is essential to create
universal definitions for the different elements of the election process. See the Data
Dictionary for the terms used by the committee in this document
Our approach was to regard elections as involving Contests between
Candidates or Referendum Options which aggregate to give results in different
Elections.
In practice however, electoral authorities would often run a number
of different elections during a defined time period. This phenomenon is captured in our
terminology as an Election Event. Figure 1B uses a British context to describe our
approach in general terms.
Figure 1B: The Election
Hierarchy
In Figure 1C, there is an Election Event called the ‘Union
Annual Election’. This comprises two Elections, one for the National Executive
Committee (NEC) and one for the International Liaison Committee (ILC). Three positions
are being selected for each committee; as a result, each Election is made up of three
Contests. In region 1 (R1), the Contest for each Election has two Candidates.
Figure 1C shows the three Ballots (one for each region). The Ballot
is personal to the voter and presents the Candidates available to that voter. It also
allows choices to be made. During the election exercise, each voter in region 1 (R1)
receives only the region 1 ballot. This ballot will contain the Candidates for the R1
contest for each of the two Elections.
Figure 1C: Union Annual
Election
Section 3 describes two complementary high level process models of
an election exercise, based on the human and technical views of the processes involved.
It is intended to identify all the generic steps involved in the process and all the
areas where data is to be exchanged highlight all the areas where data is to be
exchanged.
This high-level process model is derived from real world
election experience and is designed to accommodate all the feedback and input from the
members of this committee.
For clarity, the whole process can be divided into 3 major areas,
pre election, election, post election; each area involves one or more election processes.
This document allocates a range of numbers for each process. One or more XML schemas are
specified to support each process, this ensures consistency with all the figures and the
schemas required:
· Pre election
· Election (100)
· Candidates (200)
· Options (600)
· Voters (300)
· Election
· Voting (400)
· Post election
· Results (500)
· Audit
· Analysis
Some functions belong to the whole process and not to a specific
part:
· Administration
Interface
· Help Desk
This is the process of approving nominees as eligible candidates for
certain positions in an election. A candidate in this context can be a named individual
or a party.
Figure 2C: The Candidate Nomination
Process
Irrespective of local regulations covering the nomination process,
or the form in which a candidate’s nomination is to be presented, (e.g. written or
verbal), the committee anticipates that the process will conform to the following
format:
· Voter Communications
[350-Generic] declaring the opening of nominations will be used to reach the population
eligible to nominate candidates for a position x in an election y.
· Interested parties
will respond in the proper way satisfying the rules of nomination for this election with
the objective of becoming running candidates. The response message conforms to schema
210.
· A nomination for an
individual candidate can be achieved in one of two ways:
· A Nominee will reply
by attaching to his nomination a list of x number of endorsers with their signature.
· Each endorser will
send a message specifying Mr. X as his or her nominee for the position in question. Mr X
will signal his agreement to stand.
Note that nomination and the candidate’s agreement to stand
might be combined in a single message or sent as two messages, each conforming to schema
210.
The election officer(s) of this specific election will scrutinize
those replies by making sure the requirements are fully met. Requirements for nomination
vary from one election type to another, for example some elections require the nominee
to:
· Pay fees,
· Have x number of
endorsers,
· Be of a certain
age,
· Be a citizen more
than x number of years,
· Not stand for
election in more than one contest at a time,
· Etc.
Schema 210 provides mechanisms to identify and convey scrutiny data
but since the laws of nomination vary extensively between election scenarios, no specific
scrutiny data is enumerated.
Schema 120 allows election officials to enquire of other
jurisdictions whether a particular candidate is standing in more than one contest.
Nominees will be notified of the result of the scrutiny using a
message conforming to schema 220.
The outcome of this process is a list of accepted candidates that
will be communicated using a message conforming to schema 230. It will be used to
construct the list of candidates for each contest.
This is the process of approving the options to be presented to
voters in a referendum. The options can be a straight choice, e.g. YES or NO, to a single
question, or can be more complex involving choices to a number of questions and/or
preferences of choice.
Figure 2D: Referendum Options Nomination
Process
The nomination can be received in a number of ways including direct
from government institutions or from citizens or businesses, and schema 610 handles the
receipt of nominations.
Nominees may be notified of the result of any scrutiny of their
nomination using a message conforming to schema 620.
The outcome of this process is a list of accepted options that will
be communicated using a message conforming to schema 630. It will be used to construct
the list of referendum questions for each contest.
This is the process of recording a person’s entitlement to
vote on a voter registration system. A key part of this process is the identification of
the person.
Figure 2E: Voter
Registration
The centre of this process is the Electoral Roll Database or the
Voters’ Database. The input into this database is the outcome of communications
between ’a voter’ and ’an Election Authority‘. The subject of
this correspondence can vary from adding a voter to modifying a voter; deletion of a
voter is considered as part of modification.
This schema of data exchange is recommended irrelevant of the method
a voter uses to supply his information. For example, a voter could register online or
simply by completing a voter’s form and posting the signed form. In the latter
case, this schema is to be followed when converting the paper form into the electoral
database.
Another potential communication or exchange of data is with other
databases such as those used by another election authority, government body, etc.
Database exchanges will be required in some election scenarios; examples include
geographical and organizational boundary changes.
At a certain date, a subset of the voters' database is fixed from
which the election list is generated. Schemas contain some subset of the eligible voters,
perhaps grouped by polling district or voting channel.
It is here that we introduce the concept of voter communications.
Under this category we divided them into three possible types of communications:
· Channel options
· Polling
Information
· Generic.
The communication method between the Election Authority and the
voters is outside the scope of this document, so is the application itself. This document
does specify the data needed to be exchanged.
This is the process that involves the authentication of the voter
and the casting of an individual vote.
Figure 2F: The Voting
Process
We assumed various systems would be involved in providing the voting
process and regard each system as an independent entity.
As this figure shows, the voter will be voting using a choice of
physical channels such as postal or paper ballot (the ’physical access
methods‘), or the voter can vote using ’electronic access methods‘
where he/she can utilize a number of possible e-voting channels.
Each channel may have a gateway acting as the translator between the
voter terminal and the voting system. Typically, these gateways are in proprietary
environments. The following schemas are to be used when interfacing to such gateways:
410, 420, 430, 440 and 450. These schemas should function irrespective of the application
or the supplier’s favored choice of technology.
When a pre-ballot box is required in a scenario, schema 445 can be
used to retrieve and amend votes before they are counted.
Where a voter’s right to vote in any particular contest needs
to be determined, this is defined by the parameters of his VToken. See Section 4 for more
information on security and the VToken.
In some scenarios the right to vote may need to be qualified. This
may occur if the voter’s right to vote is challenged or if the voter is given the
temporary right to vote. In this case the vote needs to be cast by a voter with a
Qualified VToken. The reason for the qualification shall always be present in a Qualified
VToken and the qualification may need to be investigated before the vote is counted as
legitimate. The VToken and Qualified VToken are part of schemas 420, 440, 450, 460 and
470.
To create balloting information, input data is needed about the
election, the options/candidates available and the eligible voters; see schemas 230, 110
and 120 for exchanging such information between e-systems.
Two of the post election items are the Final or Interim Result and
the Audit Report. Audit is discussed in 3.4.6.
Figure 2G: The Vote Reporting
Process
The voting system should communicate a bulk of data representing the
votes to the counting system or the analysis system-using schema 460. The count of these,
which is the compilation of the 460, is to be communicated by the schema 510.
Recount can be very simply accommodated by a re-run of the schema
460, on the same or another counting system.
Some voting methods, such as the additional member system (AMS),
combine the result of one election with the votes of another to create a result. For an
election run under the AMS, the results of the ‘first past the post’ (FPP)
election can be communicated using a message conforming to schema 520. This schema can
only be used for communicating the results of elections using simple voting methods such
as FPP, and is not intended as a general purpose results schema.
The votes schema 460 also feeds into an analysis system, which is
used to provide for demographic or other types of election reports. The output of the
analysis system is outside the scope of this document.
Schemas 510 and 520 allow for Simulation and Extrapolation of final
or interim Counts and Results. Simulation being the facility to forecast the result
of a contest based on the result of another contest. Extrapolation is the facility
to forecast the final result of a contest based on the count so far.
Further schemas may be developed that make use of the Votes and
Count schemas. For example schemas for messages that report election results to the
media.
Audit is the process by which a legal body consisting of election
officers and candidates’ representatives can examine the processes used to collect
and count the vote, thereby proving the authenticity of the result.
Figure 2H: Auditing System
A requirement is for the election officer to be able to account for
all the ballots. A count of ballots issued should match the total ballots cast, spoiled
and unused.
Schemas 460, 470, 480 from the voting process provide input data to
the audit process. Depending on the audit requirements additional data from other
processes may be required. In particular, the security process may provide additional
data about all the issued VTokens and Qualified VTokens (see Figure 3A: Voting system
security).
The security process ensures that the right to cast a vote is
dictated by the presence of a VToken, thus in order to provide accountability for all
ballots as per the requirement above, reliable data from the security system is required
on the total number of:
· Eligible voters
· Issued VTokens or
Qualified VTokens.
The audit process can collate the total number of VTokens and
Qualified VTokens provided by the security system with the total number reported by the
voting system using schema 460 and 470.
The security system and sealing mechanism should be implemented so
that trust can be placed in the seal and hence the sealed data. This implies that the
seal should be performed as close to the user submission of the vote as technically
possible. The count of the spoiled and unspoiled votes from 460 can then be cross-checked
against the count of the number of trusted seals from 480. This correlation confirms that
the total number of votes presented by the output of the e-voting system in 460 is
consistent with the total number of submitted votes with seals.
The above correlation between trusted data provided by the security
process and data provided by the voting process proves that no legitimate votes have been
lost by the voting system. It also proves that there is consistency between the number of
eligible voters and the spoiled, unspoiled and unused votes as recorded by the e-voting
system.
Another requirement is for the election officer to be able to prove
that voted ballots received and counted are secure from any alteration. This requirement
is met because each vote cast is sealed; the seal can be verified by the audit system and
to prove that no alterations have been made since the vote was sealed.
A further requirement is for the election officer to be provided
with a mechanism to allow a recount when a result is contested. The number of votes from
the voting system using schema 460 can be verified by correlating the total votes as
calculated by the audit system (using schema 480), with the totals from the counting
system. Then either re-running the count or running the count on another implementation
can verify an individual result.
There is also the requirement for the election officer to be
provided with a mechanism that allows for multiple observers to witness all the voting
process. How this is achieved in dependant on the implementation of the system and
procedures adopted. However, the seals and channel information using schema 480 provide
the ability to observe voting inputs per channel while voting is in progress without
revealing the vote itself or the voter’s identity. The final count of the seals can
then be used to cross check the totals of the final result as described above.
The above defines some of the election data that can be verified by
the audit system. However, ideally everything done by the various components of an
election system should be independently verifiable. In the scope of EML this means that
the audit system may need to be able to process all the standardized EML schemas. The
audit system may in addition support proprietary interfaces of voting systems to enhance
visibility and correctness of the election process.
The data used in all the above processes are defined in ‘EML
v5.0 Data Dictionary’.
This section presents a general discussion of many of the security
considerations commonly found in many election environments. As presented previously,
these standards apply at EML interface points and define data security mechanisms at such
interface points. This document is not intended to provide a complete description, nor a
set of requirements for, secure election systems. In fact, the data security mechanisms
described in this document are all optional, enabling compliance with these standards
without regard for system security at all.
This discussion is included here simply to show how the information
passed through the various interfaces described in these standards could be secured and
used to help meet some of the requirements commonly found in some elections
scenarios.
The security governing an election starts before the actual vote
casting. It is not only a matter of securing the location where the votes are stored. An
intensive analysis into security related concerns and possible threats that could in one
way or another affect the election event resulted in the following:
· Security
considerations of e-voting systems include:
· Authentication
·
Privacy/Confidentiality
· Integrity
· Non-repudiation
This is checking the truth of a claim of identity or right to vote.
It aims to answer questions such as “Who are you and do you have the right to
vote?”
There are two aspects of authentication in e-voting systems:
· Checking a claim of
identity
· Checking a right to
vote.
In some e-voting scenarios the two aspects of authentication,
checking a claim of identity and checking a right to vote, may be closely linked. Having
checked the identity of the voter, a list of authorized voters may be used to check the
right to vote.
In other scenarios the voter’s identity must remain private
and must not be revealed by a ballot. In which case some systems may provide a clear
separation between checking of the claim of identity, which may be done some time before
the ballot takes place, from checking the right to vote at the time of the vote is cast.
Alternatively, other mechanism may be used to ensure the privacy of the voter’s
identity on cast votes (i.e. by anonymizing the ballot).
In the physical voting world, authentication of identity is made by
using verifiable characteristics of the voter like handwritten signatures, address, etc
and physical evidence like physical IDs; driver’s license, employee ID, Passport
etc, all of this can be termed a physical ‘credential’. This is often done at
the time an electoral register is set up, which can be well before the actual ballot
takes place.
Checking the authenticity of the right to vote may be performed at
various stages in the process. Initial authenticity checks may be done related to the
voter’s identity during registration.
Where an election scenario demands anonymity of the voter and
privacy of the voter’s ballot, the identity of the voter and the cast votes must be
separated at some time within the voting process. This can be done in several ways by a
voting system including, but not restricted to, the following options:
Authentication of the right to vote by itself does not reveal a
voter’s identity, but does verify he has a legitimate right to vote (e.g. the
VToken data provides authentication of the right to vote but has anonymous properties as
to the identification of the person voting).
An voter’s identity and the right to vote are both validated
(i.e. the VToken data has both ’voter identification‘ and ’right to
vote‘ authentication properties) and then the cast votes are clearly separated from
the identity of the voter (i.e. the voters identification occurs before the ballot is
’anonymized’)
In all cases any verification of the authenticity that takes place
after the voter has indicated his/her choices must preserve the privacy of those choices
according to the laws of the jurisdiction and the election rules.
Finally, when counting and auditing votes it is necessary to be able
to check that the votes were placed by those whose right to vote has been
authenticated.
Public democratic elections in particular will place specific
demands on the trust and quality of the authentication data. Because of this and because
different implementations will use different mechanisms to provide the voter credential,
precise mechanisms are outside the scope of this document.
This is concerned with ensuring information about voters and how
votes are cast is not revealed except as necessary to count and audit the votes. In most
cases, it must not be possible to find out how a particular voter voted. Also, before an
election is completed, it should not be possible to obtain a count of how votes are being
cast.
Where the user is remote from the voting system then there is a
danger of voting information being revealed to someone listening in to the
communications. This is commonly stopped by encrypting data as it passes over the
communications network.
The other major threat to the confidentiality of votes is within the
system that is collecting votes. It should not be possible for malicious software that
can collect votes to infiltrate the voting system. Risks of malicious software may be
reduced by physical controls, careful audit of the system operation and other means of
protecting the voting systems.
Furthermore, the results of voting should not be accessible until
the election is complete. Potential approaches to meeting this goal might include access
control mechanisms, very careful procedural control over the voting system, and various
methods of protecting the election data using encryption techniques.
This is concerned with ensuring that ballot options and votes are
correct and unaltered. Having established the choices within a particular ballot and the
voter community to which these choices apply, the correct ballot information must be
presented to each voter. Also, when a vote is placed it is important that the vote is
kept correctly until required for counting and auditing purposes.
Using authentication check codes on information being sent to and
from a remote voter’s terminal over a communications network generally protects
against attacks on the integrity of ballot information and votes. Integrity of the ballot
and voting information held within computer systems may be protected to a degree by
physical controls and careful audit of the system operation. However, much greater
confidence in the integrity of voting information can be achieved by using digital
signatures or some similar cryptographic protection to “seal” the data.
The fundamental challenge to be met is one of maintaining voter
privacy and maintaining the integrity of the ballot.
Non-repudiation is a derivative of the identification problem.
Identification in e-voting requires that the system provide some level of assurance that
the persons representing themselves as valid participants (voters, election workers,
etc.) are, in fact, who they claim to be. Non-repudiation requires that the system
provides some level of assurance that the identified participant is not able to
successfully assert that the actions attributed to them via the identification mechanism
were, in fact, performed by someone else. The two requirements are related in that a
system with a perfect identification mechanism and undisputable proof of all actions
would leave no room for successful repudiation claims.
Non-repudiation also requires that the system provide assurance that
data or actions properly associated with an identified participant can be shown to have
remained unaltered once submitted or performed. For example, approved candidate lists
should be verified as having come from an authorized election worker, and voted ballots
from a valid voter. In both cases the system should also provide a way to ensure that the
data has remained unchanged since the participant prepared it.
Non-repudiation is not only a technical quality of the system. It
also requires a certain amount of pure policy, depending on the technology selected. For
example, in a digital signature environment, signed data can be very reliably attributed
to the holder of the private key(s), and can be shown to be subsequently unmodified. The
policy behind the acceptance of these properties, however, must be very clear about the
responsibilities of the private key holders and the required procedures for reporting
lost or stolen private keys. Further, and especially in “mixed-mode”
elections (where voters can chose between multiple methods of voting), it may often be
desirable to introduce trusted time stamps into the election data stream, which could be
used to help determine acceptance criteria between ballots, or help resolve issues with
respect to the relative occurrence of particular events (e.g. ballot cast and lost keys
reported). The presence of the time information itself would not necessarily enable
automatic resolution of these types of issues, but by providing a clear ordering of
events could provide data that can be fed into decisions to be made according to
established election policy.
The following security terms are used in this document:
· Identity
Authentication: the means by which a voter registration system checks the validity of the
claimed identity.
· Right to vote
authentication: the means by which the voting system checks the validity of a
voter’s right to vote.
· VToken: the means by
which a voter proves to an e-voting system that he/she has the right to vote in a
contest.
· VToken Qualified: the
means by which a VToken can be qualified. The reason for the qualification is always
appended to a VToken that is qualified. For example, a qualified VToken may be issued to
a challenged voter.
· Vote sealing: the
means by which the integrity of voting data (ballot choices, vote cast against a given
VToken) can be protected (e.g. using a digital signature or other authentication code) so
that it can be proved that a voter’s authentication and one or more votes are
related.
Electronic voting systems have some very specific security
requirements that include:
· Only legitimate
voters are allowed to vote (i.e. voters must be authenticated as having the right to cast
a vote)
· Only one set of
choices is allowed per voter, per contest
· The vote cannot be
altered from the voter’s intention
· The vote may not be
observed until the proper time
· The voting system
must be accountable and auditable
· Information used to
authenticate the voter or his/her right to vote should be protected against misuse (e.g.
passwords should be protected from copying)
· Voter privacy must be
maintained according to the laws of the election jurisdiction. (Legal requirements of
public elections in various countries conflict. Some countries require that the vote
cannot be tracked back to the voter’s identity, while others mandate that it must
be possible to track every vote to a legitimate voter’s identity)
· The casting options
available to the voter must be genuine
· Proof that all
genuine votes have been accurately counted.
There are some specific complications that arise with respect to
security and electronic voting that include:
· Several technologies
may be employed in the voting environment
· The voting
environment may be made up of systems from multiple vendors
· A voter may have the
option to vote through alternative delivery channels (i.e. physically presenting
themselves at a poling station, by post, by electronic means)
· The voting systems
need to be able to meet various national legal requirements and local voting rules for
both private and public elections
· Need to verify that
all votes are recorded properly without having access to the original input
· The mechanism used
for voter authentication may vary depending on legal requirements of the contest, the
voter registration and the e-voting systems for private and public elections
· The user may be
voting from an insecure environment (e.g. a PC with no anti-virus checking or user access
controls).
In addition, the objectives of security architectures for electronic
voting systems should include:
· Being open
· Not restricting the
authentication mechanisms provided by e-voting systems
· Specifying the
security characteristic required of an implementation, allowing for freedom in its
precise implementation.
· Providing the means
to exercise security isolation and controls at interfaces between various election
processes, thereby providing the ability to implement isolated trusted logic processes to
meet dedicated functions of an election service. Process security isolation ensures that
one voting sub-process does not inadvertently effect another voting sub-process thereby
undermining the whole voting system.
The architecture proposed here is designed to meet the security
requirements and objectives detailed above, allowing for the security complications of
e-voting systems listed.
The architecture is illustrated in figure 3a below, and consists of
distinct areas:
· Voter identification
and registration
· Right to vote
authentication
· Protecting exchanges
with remote voters
· Validating Right to
Vote and contest vote sealing
· Vote
confidentiality.
· Candidate list
Integrity
· Vote counting
accuracy
· Voting system
security controls.
The Voter identification and registration is used to identify an
entity (e.g. person) for the purpose of registering the person has a right to vote in one
or more contests, thus identifying legitimate voters. The security characteristics for
voter identification are to be able to authenticate the identity of the legal person
allowed to vote in a contest and to authenticate each person’s voting rights. The
precise method of voter identification is not defined here, as it will be specific to
particular voting environments, and designed to meet specific legal requirements, private
or public election and contest rules. The voter registration system may interact with the
e-voting system and other systems to define how to authenticate a voter for a particular
contest.
Voter identification and registration ensures that only legitimate
voters are allowed to register for voting. Successful voter registration will eventually
result in legitimate voters being given a means of proving their right to vote to the
voting system in a contest. Depending on national requirements or specific voting
rules/bylaws the voter may or may not need to be anonymous. If the voter is to be
anonymous, then there must not be a way of identifying a person by the means used to
authenticate a right to vote to the e-voting system. Right to vote authentication is the
means of ensuring a person has the right to cast a vote, but it is not the identification
of the person.
Proof of the right to vote is done by means of the VToken, which is
generated for the purpose of authentication that the voter has a legitimate right to vote
in a particular contest.
The security characteristic of the VToken and hence its precise
contents may vary depend on the precise requirements of a contest, the supplier of the
voter registration system, the e-voting system, the voting channel or other parts of the
electoral environment. Thus, the content of the VToken will vary to accommodate a range
of authentication mechanisms that could be used, including; pin and password, encoded or
cryptographic based password, hardware tokens, digital signatures, etc.
The contents of the VToken may also depend on the requirements of a
particular contest, which may mandate a particular method be used to identify the person
and the voter. For example, if a country has a national identity card system, it could be
used for the dual purpose of identifying the person and providing proof that the person
is entitled to vote, provided the legal system (or the voting rules of a private
election) allow a personal identity to be associated with a vote. However, this would not
work for countries or private voting scenarios that require the voter to be anonymous.
For such a contest the mechanism used to identify that a person has the right to cast a
vote must not reveal the identity of the actual person, thus under such voting rules
voter identity authentication and right to vote authentication do not use the same
information or semantics.
The security characteristic required of the VToken may also vary
depending on legal requirements of a country or electoral rules used in a particular
contest. Also, the threats to misuse of VTokens will depend to a large degree on the
voting channels used (e.g. physical presence at voting station, Internet, mobile phone).
Bearing this in mind the XML schema of the VToken components must allow for various data
types of authentication information to be contained within it.
It must be possible to prove that a VToken is associated with a vote
cast and the rules of the contest are followed, such as only one vote being allowed per
voter, per contest. Thus providing proof /non-repudiation that all votes were genuine,
they were cast in accordance with the rules of the contest, that no vote has been altered
in any way and that all the votes counted in a contest were valid when audited.
Depending on the legal requirements of a country or electoral rules
a voter may be challenged as to the right to vote, or may be given a temporary right to
vote. In such cases the VToken may need to be qualified with a reason. In this document
this is called a VToken Qualified. Before a vote is considered legitimate and counted the
reason for the qualification must have been suitably scrutinized, which could be done by
the voting officials.
The VToken may be generated as part of the registration system, the
e-voting system, or as interaction between various components of a voting environment, as
illustrate in Figure 3a. The VToken will need to be provided securely to the voter so
that this can be used to prove the right to vote.
The exchange of information when casting a vote must be protected by
secure channels to ensure the confidentiality, integrity of voting data (VToken(s) and
vote(s) cast) and that this is correctly delivered to the authenticated e-voting system.
If the channel isn’t inherently secure then this will require additional protection
using other mechanisms. Possible mechanisms might include: a postal system with sealed
envelopes, dedicated phone channel, secure e-mail, secure internet link (SSL), peer to
peer server/client authentication and a seal.
Wherever technically possible the exchange of information should be
secured and integrity guaranteed even if non-secure communications channels are used.
When a vote is cast, to ensure that it cannot be altered from the
voter’s intention, all the information used to authenticate the right to vote and
define the vote cast must be sealed to ensure the integrity and non-repudiability of the
vote. This seal may be implemented using several mechanisms ranging from digital
signatures (XML and CMS), cryptographic seals, trusted timestamps and other undefined
mechanisms. The seal provides the following security functions:
· The vote cannot be
altered from the voter’s intention
· The voting system is
accountable and auditable.
The right to vote may be validated at the time the vote was cast. If
votes are not checked for validity before sealing then the right to vote must be
validated at the time that votes are subsequently counted. Also when counting, or
otherwise checking votes, the validity of the seal must be checked.
If votes are sealed and recorded without being checked for validity
at the time they were cast, then the time that the vote was cast must be included in the
seal, so that they may be checked for validity before they are counted.
In some election scenarios it is required to audit a vote cast to a
particular voter, in this case a record is also needed of the allocation of a VToken to a
voter’s identity. Such systems also provide non-repudiation of the voter’s
actions. In such cases a voter cannot claim to have not voted or to have voted a
different way, or that his vote was not counted. In many election scenarios where this
type of auditing is required, it must not be easy to associate a VToken to the
Voter’s identity, therefore this type of records must be under strict control and
protected by security mechanism and procedures, such as; encryption, key escrow and
security operating procedures.
All cast votes must not be observed until the proper time, this
requires confidentiality of the vote over the voting period, how this is achieved will
vary from e-voting system to e-voting system. Mechanism of vote confidentiality, range
from trust in the e-voting systems internal security functions (processes and mechanisms)
to encryption of the data, with key escrow tools.
To ensure that the voter is present and that the candidate list is
genuine, there must be a secure channel between the voting system and the person voting
or the data must be sealed. The approach selected must ensure that there is no
man-in-the-middle that can change a vote from what the voter intended. There are various
ways this requirement can be met, ranging from the candidate list having unpredictable
characteristics with a trusted path to convey that information to the voter, to trust
placed in the complete ballot/vote delivery channel.
As an example, there may be a secure path to convey the VToken to
the person entitled to vote, a way of ensuring that a voter is always presented with a
genuine list of candidates might be to encode the candidate list as part of a sealed
VToken.
In summary, there must be a way of ensuring the validity of the
ballot options and voter selection.
Audit of the system must be able to prove that all vote casts were
genuine and that all genuine votes were included within the vote count. Voters may need
to be able to exercise that proof should they so desire. Thus auditing needs data that
has non-repudiation characteristics, such as the VToken/vote sealing, see schema 470 and
480.
The overall operation of the voting systems and its physical
environment must be secure. Appropriate procedural, physical and computing system
controls must be in place to ensure that risks to the e-voting systems are met. There
must be a documented security policy based upon a risk analysis, which identifies the
security objectives and necessary security controls.
Figure 3A: Voting system
security
Many new election systems are currently under evaluation. These
systems tend to offer deployment options in which the communication between the voter and
the election officials is carried out in an environment that is not completely under the
control and monitoring of the election officials and/or election observers (e.g., the
Internet, private network, telephones, cable TV networks, etc.). In these
’remote‘ or ’unattended‘ environments, several particular
security concerns and questions like:
· How do I know that
that the candidate information I am being presented with is the correct information?
· How do I know that my
vote will be recorded properly?
· How do I know there
isn't a man-in-the-middle who is going to alter my vote when I place it?
· How do I know that it
is the genuine e-voting server I'm connected to that will record my vote rather than one
impersonating it that's just going to throw my vote away?
· How do I know that
some component of the system does not have malicious software which will attempt to alter
the ballot choices as represented to me or alter my election?
The type and importance of a particular contest will have an effect
on whether the above concerns exist and whether they do, or do not, represent a tangible
threat to the voting process and its outcome. The table listed at Appendix A shows the
concerns that have been identified as possibilities for one such remote or unattended
environment (the Internet) that could be used in public election voting scenarios. The
table shows how the concerns can be translated to technical threats and characterizes
security services that may be used to counter such threats. Many of the items are not
unique to the Internet, and can serve as a useful reference or starting point in
developing similar threat analysis for other digital and/or unattended voting
environments. How the security services are implemented in any particular environment or
deployment is outside the scope of this document allowing freedom to the system
providers.
The Election Markup Language specification defines a vocabulary (the
EML core) and message syntax (the individual message schemas). Thus most voting-related
terms are defined as elements in the core with the message schemas referencing these
definitions. The core also contains data type definitions so that types can be re-used
with different names (for example, there is a common type to allow messages in different
channel formats), or used as bases for deriving new definitions.
In some cases, two or more message schemas have large parts in
common. For example, a voter authentication response message can contain a ballot that is
almost identical to that used in the ballot message. When this occurs, the relevant
declarations are included in a file whose file name includes the word
‘include’ and the number of the schemas in which it is used.
There is a third category of schema document within EML - the EML
externals. This document contains definitions that are expected to be changed on a
national basis. Currently this comprises the name and address elements, which are based
on the OASIS Extensible Name and Address Language [1], but may be replaced by national
standards such as those contained in the UK Government Address & Personal Details
schemas [2]. Such changes can be made by replacing just this single file.
As well as these, several external schemas are used. The W3C has
defined a standard XML signature [5]. OASIS has defined schemas for the extensible Name
and Address Language (xNAL) [1]. As part of the definition of EML, the committee has
defined a schema for the Timestamp used within EML. All these schemas use their
appropriate namespaces, and are accessed using xs:import directives.
Each message (or message group) type is specified within a separate
schema document. All messages use the EML element from the election core as their
document element. Elements declared in the individual schema documents are used as
descendents of the EML element.
XML elements may have an identifier which is represented as an Id
attribute.
Each schema element has an Id attribute that relates to the message
numbering scheme. Each message also carries this number.
Some items will have identifiers related to the voting process. For
example, a voter might be associated with an electoral roll number or a reference on a
company share register. These identifiers are coded as elements.
Other identifiers exist purely because of the various channels that
can be used for voting (e.g. Internet, phone, postal, etc). In this case the identifiers
are likely to be system generated and are coded as attributes.
Many e-voting messages are intended for some form of presentation to
a user, be it through a browser, a mobile device, a telephone or another mechanism. These
messages need to combine highly structured information (such as a list of the names of
candidates in an election) with more loosely structured, often channel-dependent
information (such as voting instructions).
Such messages start with one or more Display elements, such as:
<?xml version="1.0" encoding="UTF-8"?>
<EML
Id="410"
SchemaVersion="0.1"
xml:xml:lang="en"
xmlns="http://www.govtalk.gov.uk/temp/voting"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.govtalk.gov.uk/temp/voting
..\schemas\ballot.xs">
<Display Format="html">
<Stylesheet
Type="text/xsl">../stylesheets/ballot.xsl</Stylesheet>
<Stylesheet
Type="text/css">../stylesheets/eml.css</Stylesheet>
</Display>
<Ballots>
...
This example shows a Display element providing information to the
receiving application about an XSL stylesheet which transforms the message into HTML for
displaying the ballot in a Web browser. In the Display element in the example, the XSLT
stylesheet reference is followed by a CSS stylesheet reference. In this case, the XSLT
stylesheet referenced will pick up the reference to the CSS stylesheet as it transforms
the message, and generate appropriate output to enable the displaying browser to apply
that cascading stylesheet to the resulting HTML.
Not all information in a message will need to be displayed, and the
creator of the message might have views on the order of display of the information. To
allow stylesheets to remain generic, many elements in the schemas can have a DisplayOrder
attribute. The values of these attributes determine the layout of the display (or the
spoken voice if transforming to, for example, VoiceXML), even when using a generic
stylesheet.
When displaying messages in HTML, the expectation is that generic
stylesheets will cover most cases, with the stylesheet output being embedded in a web
page generated from an application-specific template. Similarly, voice applications might
have specific welcome and sign-off messages, while using a generic stylesheet to provide
the bulk of the variable data.
The three screen shots show the effect of using the same XSL
stylesheet on the ballots for various voting scenarios. In the first picture, clicking on
the name of a candidate has popped up a window with additional details.
Figure 3A: Screen shot of the ballot for scenario 1
Figure 3B: Screen shot of the ballot for scenario 2
Figure 3C: Screen shot of the ballot for scenario 3
Details on the description of schemas used in EML v5.0 can be found
within the document ‘EML v5.0 Schema Descriptions’.
The following individuals have participated in the creation of this
specification and are gratefully acknowledged:
Participants:
Charbel Aoun, Accenture
Siobhan Donaghy, OPT2VOTE Ltd
Bruce Elton, Oracle Corporation
Joseph Hall, University of California, Berkeley
Roy Hill, OPT2VOTE Ltd
John Ross, Associate
Paul Spencer, Associate
Johan Terryn, EDS
Bernard Van Acke, IBM
David Webber, Individual
Peter Zelechoski, Associate
B.1
Internet Voting Security Concerns
|
Concerns raised on Internet voting
|
Resulting Technical Threats
|
Possible generic security service
countermeasure
|
|
1.
|
Impersonation of the right to vote.
The concern here is that a person attempts to
impersonate to be a legitimate voter when he/she is not.
The initial task of verifying that a person has the
right to vote must be part of the voter registration process.
A person must not be given the right to vote until
after proper due diligence has been undertaken during voter registration that the person
has a right to vote in a contest.
|
Inadequate, incorrect or improper identification of
person during registration of voters
|
Trusted voter identification and registration
using:
Security Procedures.
Best Practices.
Secure communications channels.
The voter registration authority must follow standard
Security Operating Procedures (SOPs) which ensure due diligence has been done.
|
|
Inadequate privacy of the exchange between the person
and the electoral system during voter registration
|
Channel between voter and registration system must
provide:
Connection Confidentiality
Connection Integrity
|
|
2
|
Voter is not presented with correct ballot
information due to incorrect candidate identification.
|
Incorrect identification during candidate
registration.
|
Trusted candidate identification and registration are
needed using:
- Security Procedures.
- Best Practices.
- Secure communications channels.
- Authentication and identification of
candidates
The candidate registration must follow standard
Security Operating Procedures (SOPs) which ensure due diligence has been done.
|
|
3
|
Registration system impersonation
|
Inadequate authentication of registration
system
|
Channels to and from the registration system must
provide point to point authentication.
|
|
4
|
Impersonation of a legitimate registered
voter
|
Incorrect authentication at the time of casting
vote.
|
Trusted voter authentication
(i.e. the right to cast a vote in this
contest)
|
|
Inadequate privacy of the exchange between the voter
and the electoral system when vote is cast.
|
Channel to provide:
- Connection Confidentiality
- Connection Integrity
- Between voter and e-voting system
|
|
5
|
Obtaining the right to vote illegally from a
legitimate voter.
This may be by intimidation, theft or by any other
means by which voting right has been obtained illegally.
For example, by
Stealing a voting card from a legitimate
voter.
|
Stealing the voter’s voting card (e.g. the
VToken data).
|
Some secret data only known to the voter’s is
required to be presented at the time of casting a vote.
Before a vote is counted as a valid vote proof must
be provided that the voter’s secret data was present at the time of casting the
vote.
|
|
Any means of getting a legitimate voter to reveal his
VToken data.
|
|
6
|
Voting system impersonation
|
Inadequate authentication of registration
system
|
Channel to provide:
Point to point authentication
|
|
Inadequate authentication of voting casting
point
(e.g. polling station/ballot box)
|
Channel to provide:
Point to point authentication
|
|
7
|
Voter is not presented with correct ballot
information
|
Inadequate integrity of the ballot
information
Given to the user
Held in the voting system
|
Trusted path to voter on ballot options
|
|
Integrity of the ballot information
|
|
Integrity of cast votes
|
|
The casting options available to the voter are not
genuine
|
Trusted path between voter and vote
recording
|
|
Trojan horse, man in the middle attack
|
Trusted path to voter on ballot options
|
|
8
|
How do I know the voting system records votes
properly
|
Integrity of the voting system
|
Non-repudiation of the vote
|
|
Non-repudiation the vote was cast by a genuine
voter
|
|
Audit of voting system
|
|
Connection confidentiality
|
|
|
|
Insecure channel between the voter and the vote
casting point
|
Connection Integrity
|
|
Connection Confidently
|
|
Voter’s intent is recorded
accurately
|
Trusted path between voter and vote
recording
|
|
Non-repudiation of the vote recorded
|
|
Proof that a genuine vote has been accurately
counted
|
Audit
|
|
9
|
How can I be sure the voting system will not disclose
whom I have voted for
|
Voter’s identification is revealed
|
Voter’s identification is anonymous
|
|
Vote confidentiality
|
|
10
|
How can it be sure that my vote has been
recorded
|
Loss of vote
|
Proof of vote submission
|
|
11
|
How can I be sure there is no man-in-the- middle that
can alter my ballot
|
Vulnerable client environment;
Trojan horses
Virus
|
Physical security
|
|
Procedural security
|
|
Unpredictable Coded voting information
|
|
Interception of communication
|
Integrity of communications channel between client
and server system
|
|
12
|
All votes counted must be have been cast by a
legitimate voter
|
Voter impersonation
|
Voter authentication
|
|
Audit facility fails to provide adequate
proof
|
Non-repudiation of the vote record
|
|
Non-repudiation that legitimate voters have cast all
votes.
|
|
Breaking the vote counting mechanisms
|
Independent audit
|
|
13
|
Only one vote is allowed per voter, per
contest
|
Voter impersonation at registration
|
User registration security
Procedures
Voter Identification
|
|
Multiple registration applications
|
|
Multiple allocation of voters credentials
|
Voter authentication
|
|
14
|
The vote cannot be altered from the voter’s
intention
|
Vulnerable client environment;
Trojan horses
Virus
|
Trusted path from voter’s intent to vote
record
|
|
Vote integrity
|
|
Vote non-repudiation
|
|
15
|
The vote may not be observed until the proper
time
|
Votes may be observed before the end of the
contest
|
Voter confidentiality
|
|
16
|
The voting system must be accountable and
auditable
|
|
Non-repudiation of vote data.
|
|
Audit tools
|
|
17
|
Identification and authentication information to and
from the voter must be privacy protected
|
Loss of privacy
|
Channel to provide:
Connection Confidentiality
|
|
18
|
The voter’s actual identity may need to be
anonymous
|
Voter’s identification is revealed
Denial of service attack
|
Voter’s identification is anonymous
|
|
19
|
Denied access to electronic voting station
|
|
This needs to be counted by engineering the system to
provide survivability when under denial of service attack.
|
B.2 The
Timestamp Schema
Although used as part of EML, this schema has been put in a separate
namespace as it is not an integral part of the language. A time-stamp binds a date and
time to the sealed data. The time-stamp seal also protects the integrity of the data. The
structure of the time-stamp is similar to the structure of an XML Signature. The
structure of the Timestamp element is shown here, followed by the detail of two of the
four data types that are used to define its child elements.
The timestamp structure may be used in one of two ways either:
· Using Internet RFC
3161 binary encoded time-stamp token with the time-stamp information repeated in XML,
· Using a pure XML
encoded time-stamp.
In the case of the RFC 3161 based time-stamp, the Timestamp
structure is used as follows:
· within
TimestampedInfo:
· TSTOrSignatureMethod
identifies RFC 3161.
· Reference contains
the URI reference of the voting data being time-stamped. The DigestValue sub element
contains the digest of the voting data being time-stamped.
· TSTXMLInfoReference
is not present in this case.
· SignatureOrTSTValue
holds the RFC 3161 time-stamp token applied to the digest of TimestampedInfo. The
TimestampedInfo is transformed to a canonical form using the method identified in
CanonicalizationMethod before the digest algorithm is applied.
· KeyInfo contains any
relevant certificate or key information.
Object contains the TSTXMLInfo element which is a copy of the
information in SignatureOrTSTValue converted from RFC 3161 to XML encoding. The
TSTXMLInfo element contains:
· the version of
time-stamp token format. This would be set to version 1
· the time-stamping
policy applied by the authority issuing the time-stamp,
· the time-stamp token
serial number,
· the time that the
token was issued, the contents of this element indicate the time of the timestamp.
· optionally an
indication as to whether the time-stamps are always issued in the order that requests are
received
· optionally a
nonce given in the request for the time-stamp token,
· optionally the
identity of the time-stamping authority
In the case of a pure XML encoded time-stamp, the Timestamp
structure is used as follows:
· within
TimestampedInfo,
· TSTOrSignatureMethod
identifies the algorithm used to create the signature value.
· Reference contains
the URI reference of the voting data being time-stamped. The DigestValue sub element
contains the digest of the voting data being time-stamped.
· TSTXMLInfoReference
must be present, and contains the URI reference of TSTXMLInfo as contained within the
Object element. The DigestValue sub element contains the digest of the TSTXMLInfo.
· SignatureOrTSTValue
contains the signature value calculated over the TimestampedInfo using the signature
algorithm identified in TSTOrSignatureMethod having been transformed to a canonical form
using the method identified in CanonicalizationMethod. This signature is created by the
time-stamping authority.
· KeyInfo contains any
relevant certificate or key information.
Object contains the XML encoded time-stamp information in an
TSTXMLInfo element. The contents of TSTXMLInfo is the simular as for the case described
above. However, in this case the information is directly signed by the time-stamping
authority. The TSTXMLInfo element contains:
· version of time-stamp
token format: This would be set to version 2
· the time-stamping
policy applied by the authority issuing the time-stamp,
· the time-stamp token
serial number,
· the time that the
token was issued, this is the time of the timestamp.
· optionally an
indication as to whether the time-stamps are always issued in the order that requests
were received
· optionally a nonce
given in the request for the time-stamp token,
· optionally the
identity of the time-stamping authority.
B.3 W3C
XML Digital Signature
Some information on the digital signature is included here, but for
full information refer to the Recommendation at [5].
An XML Signature consists of:
· SignedInfo which
includes a sequence of references to the data being signed with the digest (eg. SHA-1
hash) of the data being signed
· SignatureValue which
contains the signature value calculated over the SignedInfo using the signature algorithm
identified in SignatureMethod having been transformed to a canonical form using the
method identified in CanonicalizationMethod
· KeyInfo contains any
relevant certificate or key information.
· Object can contain
any other information relevant to the signature
|
Revision
|
Date
|
Editor
|
Changes Made
|
|
V0.1a
|
2002-02-07
|
P Spencer
|
Draft e-voting schemas for internal
comment
|
|
V0.2a
|
2002-02-13
|
P Spencer
|
Draft e-voting schemas for internal
comment
|
|
V0.3a
|
2002-03-22
|
P Spencer
|
Draft e-voting schemas for public consultation
comment
|
|
V0.4
|
2002-04-18
|
P Spencer
|
Draft Committee Specification version 2
|
|
V1.0
|
2002-04-29
|
P Spencer
|
Committee Specification for Technical Committee
approval
|
|
V1.0
|
2002-05-13
|
P Spencer
|
Committee Specification
|
|
V2.0a
|
2002-06-13
|
F Ahmed
|
Revised draft accommodating committee’s
comments
|
|
V2.0b
|
2002-07-15
|
F Ahmed
|
Draft Committee Specification for Technical Committee
approval
|
|
V2.0
|
2002-09-05
|
F Ahmed
|
Committee Specification
|
|
V3.0a
|
2002-12-12
|
F Ahmed
|
Draft Committee Specification
|
|
V3.0b
|
2003-02-06
|
F Ahmed
|
Draft Committee Specification for Technical Committee
approval
|
|
V3.0
|
2003-02-24
|
F Ahmed
|
Committee Specification
|
|
V4.0a
|
2003-10-05
|
J Borras
|
Revised draft accommodating requirements of Council
of Europe Member States and UK pilots
|
|
V4.0b
|
2004-01-27
|
J Borras
|
Draft Committee Specification
|
|
V4.0c
|
2004-03-09
|
J Borras
|
Revised draft by placing Schema Description section
in document of its own due to excessive size of v4.0b.
Draft Committee Specification for Technical Committee approval.
|
|
V4.0d
|
2004-09-03
|
J Borras
|
Draft Committee Specification for Technical Committee
approval.
|
|
V4.0
|
2005-01-24
|
J Borras
|
Committee Specification
|
|
V4.0
|
2006-02-01
|
J Borras
|
OASIS Standard
|
|
V5.0
|
2007-03-14
|
J Borras
|
Committee Draft
|
