You have to trust the sys admins. And as we all know: something is trusted if it can break your security policy.
You have to trust the sys admins. And as we all know: something is trusted if it can break your security policy.
Eventually someone has to trust someone to execute correctly. Unless there's some voting system I'm not aware of that doesn't require humans and is easily verifiable at the point of voting by the average voter.
Later, after the votes were tallied, the voter could verify that their ballot was (1) counted and (2) counted towards their chosen candidate. But crucially, all they could verify was that the vote counted towards position 1, or position 2, or position 3, ...
The point is that since the voter couldn't prove to a coercing party that the position they voted for was (or was not) the candidate the coercer wanted them to vote for, they were immune to coercion. They could prove that they voted for position 2, sure. But which candidate was at position 2?
The voter knows the truth because they saw the position list. However, until we have mind-reading technology, a coercing party could only take the voter's word.
[2] http://documentation.heliosvoting.org/verification-specs/hel...
[3] http://www.iacr.org/elections/eVoting/finalReportHelios_2010...
[4] http://www.iacr.org/elections/eVoting/heliosDemo.pdf
[5] https://vote.heliosvoting.org/helios/elections/1df69264-0a48...
1) Observers at polling stations.
2) Sealed ballot boxes.
3) Observers from many parties and neutrals at counts.
4) Physical votes retained and recountable.
It isn't going to be completely secure but if you measure the systems security by how few people you could rig an election with it is an order of magnitude harder [edit: to rig].
How many people can verify a digital check-sum?
In contrast regular people usually have the mental capabilities to count votes.
[1]: http://wijvertrouwenstemcomputersniet.nl/images/9/91/Es3b-en...
"I examine the question of how to design election-related software, with particular attention to the threat of insider attacks, and propose the goal of simplifying the software in electronic voting machines. I apply a technique called prerendering to reduce the security-critical, voting-specific software by a factor of 10 to 100 while supporting similar or better usability and accessibility, compared to today’s voting machines. Smaller and simpler software generally contributes to easier verification and higher confidence.
"I demonstrate and validate the prerendering approach by presenting Pvote, a vote-entry program that allows a high degree of freedom in the design of the user interface and supports synchronized audio and video, touchscreen input, and input devices for people with disabilities. Despite all its capabilities, Pvote is just 460 lines of Python code; thus, it directly addresses the conflict between flexibility and reliability that underlies much of the current controversy over electronic voting. A security review of Pvote found no bugs in the Pvote code and yielded lessons on the practice of adversarial code review. The analysis and design methods I used, including the prerendering technique, are also applicable to other high-assurance software."
(No, it doesn't solve all of your problem.)
You know, there is a technical solution to that problem:
I'm not a security expert, how effective could that be in providing this kind of verification?