[E-voting] Testing REV systems. Was: UK shelves plans for e-voting trials

Brian O'Byrne bobyrne at statesoft.ie
Thu Oct 27 11:06:57 IST 2005


Some time ago we had a conversation (UK shelves plans for e-voting 
trials) where we explored some of the attributes of an e-voting 
trial. When we left the conversation you had asked me to provide 
suggestions for such a trial.
I'd like to answer that question now (better late than never, I hope.)

There is just one feature I'd like to add to the list you prepared: 
deliberate hacking. As a part of the trial permit a few professional 
programmers and public activists to attempt to disrupt the vote. Do 
not give these people any special access or extra information (with 
one possible exception; see below). Do not allow any communication 
between these people and the main election officials. Pay these 
hackers. Pay them a reasonable rate for their time and offer a bonus 
if they manage to disrupt the election.

A few ground rules:
- Announce the testing program well before the election (at least six 
months). Remember in the real world people can anticipate elections 
years in advance.
- Run the program for at least two elections, at least six months 
apart. Again in the real world attackers will be able to learn from 
their first attempts.
- Have the tests monitored by an independent team of election 
officials. (Emphasis on independent. There must be a wall of silence 
between this team and the main election operation.)
- Have all tests vetted to ensure no-one is actually disenfranchised.
- In general a successful attack will be anything that affects the 
vote in any way and is not detected by the system (where 'system' 
includes the technology and the people). All attempted attacks will 
be monitored by the independent team to ensure no-one is actually 
- The definition of a successful test (demonstrating a failure) will 
change on a case-by-case basis depending on the attack used but might 
 Integrity breaches:
 - A voter running a client other than the official client
 - A vote being altered in transit
 Secrecy breaches:
 - Any form of evidence about how I voted
 - A vote being read by any unauthorised party
 Count failures:
 - Any attack on the count process that affects the result
 - DoS, personation, ...

In order to make it possible to attempt changes to the client the 
attackers may be allowed to host a trojaned client on the main web 
server for the election. There are lots of ways to get such a client 
onto a voter's machine but most of them are illegal and actionable by 
the owner of the machine, therefore to protect the attackers we 
should allow them this minimum of special access. Note that this will 
still not allow them to get the private keys for the client or make 
use of the certificates signing the client code, so a properly 
vigilant voter still has a fair chance of noticing the suberfuge and 
the system has a fair chance of noticing tampering with the vote 

My goal here is to convince you and others that it is not possible to 
protect the voting system sufficiently if you allow DRE or REV. In 
honesty if the voting system passes this test procedure I probably 
will still not trust it, but I don't believe you can design a system 
including REV that will stand up to this sort of test, so I'm happy 
to suggest it.

Brian O'Byrne, Statesoft Ltd.
Tel: +353 1 4100 993, +353 86 240 4719

More information about the E-voting mailing list