Security Properties for Electronic Voting
For an electronic voting system to be secure, it has to be implemented according to a secure design, to function in various environments without information flow or vulnerabilities, to be properly maintained and updated, and the list goes on. Despite the complexity of the problem, some criteria for election systems seem to be unanimously accepted as the core requirements: features that, while present, contribute to the security of the system, and while absent, drastically tamper the election process.
The list is by far complete. For example,  summarizes a set of variants of the privacy requirement:
- Accuracy. It should not be possible for a vote to be altered, or for a validated vote to be eliminated from the final tally, or for an invalid vote to be counted in the final tally().
- Eligibility and Authentication. Only authorized voters should be able to vote().
- Uniqueness. No voter should be able to vote more than one time(.)
- Integrity. Votes should not be able to be modified, forged, or deleted without detection().
- System integrity. As pointed in , once certified, the code, initial parameters, and configuration information must remain static, and no system change should be allowed during the active stages of election. One clear danger is the Trojan horse attack that might be ignored if it takes place during election.
- Data integrity. Votes must be recorded correctly and must not be changed once the voter has been certified and the vote was proved correct.
- Secrecy. No one should be able to determine how any individual voted().
- Non-coercibility. Voters should not be able to prove how they voted(); otherwise, they are able to sell their votes, or they may become victims of extortions.
- Verifiability. It should be possible to verify that all votes have been correctly accounted for in the final tally(). The testing procedures should be public, as pointed in . Public testing may be seen also as a way of facilitating decentralization, as a security guarantee.  lists some of the controls that the system should implement, and whose functionality is enhanced by decentralization: access, development and implementation controls, system plus computer operations controls, validity, processing, and input controls.
- Auditability. There should be authentic election records; the authenticity of these records should be provable().
- Reliability. Even in the event of numerous or major failures (such as loss of Internet communication), the system should be robust, and no loss of vote should happen().
- Certifiability. Election system should be testable().
- Operator authentication. Authorized observers and election administrators must gain access with nontrivial authentication mechanisms. As an example, fixed passwords are not good enough().
- System accountability(). Internal operations must be monitored, simultaneously with preserving confidentiality.
- System disclosability(). The system software, hardware, and documentation must be open() for inspection. This should be balanced with the secrecy requirement. This requirement can be formulated as an instance of the information flow problem, since documentation and implementation details should not allow any inference or disclosure of the votes-voters correspondence.
- Fail-safe voter privacy. Voter privacy must be assured even if everything fails, everyone colludes, and there is a court order to reveal all election data. In a more general formulation, voter privacy must be guaranteed against any possible failure of the system.
- Collusion-free vote secrecy. Vote secrecy must not depend only on communication protocol and cryptographic assumptions.
- Fail-safe privacy in verification. Even with court order and with large computational resources, the complete verification of (encrypted) ballots should not disclose the voter's identity for some vote.
- Allow undervotes. The voter may receive a warning of not voting, but this warning must not be public and, even more, must not prevent undervoting.
If we take into account different details of implementation, we discover more subtle security requirements. As an example,  imposes software certification, performance, and integrity by simultaneously verifying certification of software, dedicated operations and uses, together with logical correctness of vote-tallying software. The same report refines the problem of access control by requiring site controls, voting process and telecommunications security controls.
Additional features of voting systems require additional security constraints:
- Correct recounting of voter-choice sets. The system should be designed in a way that allows subsequent recounting of votes, always yielding the correct result. This implies that the counting process should not be allowed to influence the integrity of the data: after the election time expired, no modification of votes is permitted. The counting process should not be able to disclose any additional information about the identity of the voters.
- Post-election correctness verification. Verification should be permitted even after the election; in other words, even if the process is verifiable before election, it shouldn't stop being transparent after the election.
- Vote reconciliation. Additional computations followed by equality tests should not fail if the vote counting was correct.
Apart from the above security criteria, there are some desirable properties directly influencing the efficiency of the voting system, and indirectly affecting the security of the election:
There is a simple test showing that these are indeed security properties: a system that does not exhibit at least one of these features is vulnerable. If the system is not transparent, then there is no universally verifiable election protocol allowing each individual that has some knowledge about the way the system works to verify the correctness of the election. And then the system is prone to inside fraud.
- Convenience() and interface usability(). Voters should be able to cast their vote in one session, quickly, with minimal equipment; they should not be required special skills.
- Flexibility. The system should allow a variety of question formats, and it should be compatible with different standard platforms and technologies; plus, it should be accessible to people with disabilities(). Internet voting security requirements must account for environments with different threats even if system architectures are very similar.
- Mobility. Besides logistical restrictions, no other constraints should be allowed on the location from which a voter can cast the vote().
- Transparency(), documentation and assurance(). Voters should be able to posses general knowledge and understanding of the election process and how the system works. The design, implementation, and testing procedures must be documented.
- Cost-effectiveness. The election system should be affordable().
An inconvenient system may easily become the victim of unintended attacks, since it is more probable to have errors in an election process that is tedious or complicated, then it is in a quick and simple one. Voters may introduce errors, and a secure system should be able to discard all erroneous data; but if the system is intricate and requires voters with special skills, then many votes are incorrectly cast, and we end up rejecting a large fraction of all the votes. And in this way the result of the election becomes unrepresentative; even more, the segment of population that is more knowledgeable is the one to cast the vote and finally impose their choice. This leads to the opposite of the democracy and violates the principle of universal vote access.
Flexibility has been a vexing problem for the computer industry(). A secure system should support ballot design for different platforms to ensure reliability, but at the same time should evenly distribute the votes among groups with different views. It should avoid introducing bias by selecting platforms that are more available to some groups than to others(). The choice of the platform, language, ballot format, or devices may seem innocuous, but it may actually prevent small fractions of the voters to cast their vote. A secure system should not disadvantage any of the voters, and so it should also provide devices to assist disabled people.
Providing flexibility adds significantly to the complexity of the system, and increases the cost of testing and certification, and thus may have a negative result on cost-effectiveness. On the other hand, a very expensive system may be impossible to construct in the real world, or may generate negative attitude from the voters if public subvention is required.
There are multiple types of electronic voting: Internet voting, with three alternatives:
and direct recording electronic(DRE): the ballots are cast on an electronic voting machine that may occasionally send the stored votes to a central site.
The results of the election should be the same, no matter what type of electronic voting is actually implemented. However, each type of voting has its own characteristics that may facilitate specific errors, or that are more vulnerable to certain kinds of attacks. Some vulnerabilities are due to the structure of the system; for example, as pointed in , with remote Internet voting, ballots cannot be stored on client computers since if such records are maintained, then spying and vote selling are facilitated; and this just adds to the long list of network failures or attacks against routers, domain name servers, or the whole network. Different systems have different vulnerabilities, special platforms, specific risks; they also influence voter participation and access, and law enforcement mechanisms. The aim is to maintain the same functionality, at the same level of security. A secure system should:
- poll site Internet voting: ballots are cast at public sites where election officials control the voting platform()
- remote voting: ballots are cast at private sites, where a third party controls the voting client
- kiosk voting: intermediate solution, since voting terminals are located in public places, but remain under the control of election officials,
For example, computer software designers may create liabilities that are not under the control of the election officials, and the law should be updated accordingly. These are all legal concerns, but they should not be ignored or underestimated. It is impossible to have a secure election system without specific laws, clear liability, fair means of law enforcement. Public or private systems may present different laws, but a secure electronic voting should not be affected by these differences.
- defer fraud and attacks
- determine liabilities
- update voting-related laws to Internet voting.
An electronic voting system should be able to defend against:
There are three main vulnerable points: the server (the subsystem that receives all the votes), the client (the subsystem that casts the votes), and the communication path. A secure system must protect all of them. The attacks are usually malicious payload in the form of Trojan horse or remote control program. If such an attack takes place, it may never be detected, while preventing voters from casting votes, modifying or gaining information about ballots and the relationship voter-ballot. The system should be able to circumvent these attacks, independent of the actual type of electronic voting.
As an example, for remote voting, the path between the voting client and the server must be secure during vote transmission. The communication along this path should be authenticated, and data should be encrypted to preserve confidentiality.
- fraud for poll site voting()
- Trojan horse attacks: malicious, security-breaking programs disguised as something benign
- malicious use of remote control software()
- (distributed) denial of service attacks or fake voting sites(spoofing)(): the server may be flooded with more requests it can handle (this is what happens in the denial of access attack). Even more subtle, in the distributed denial of service attack, daemons may be installed on computers whose owners are unaware of the attack; these daemons perpetrate the attack().
- social engineering(): attacks that involve fooling people into compromising their security.
Many of the above criteria for the security of electronic voting are impossible to achieve at the same time. This justifies the need for a managed risk approach to security. As explained in , the concept of risk, as used for this problem, is a measure of both likelihood and the consequence of an adverse event. Different types of electronic voting have different risks. We have to choose the type that minimizes the risk.
- D. M. Elliott,Examining Internet voting in Washington
- L. F. Cranor,Design and implementation of a practical security-conscious electronic polling system,1996
- P. G. Neumann,Security criteria for electronic voting
- A. Rubin,Security considerations for remote electronic voting over the Internet
- R. G. Saltman,Accuracy, integrity, and security in computerized vote-tallying,1988
- M. I. Shamos,Electronic voting- evaluating the threat,1993
- Report of the National Workshop on Internet Voting: Issues and Research Agenda,2001
- Online voting,Parliamentary Office of Science and Technology,2001
- Voting system requirements,Safevote