[E-voting] Testing REV systems. Was: UK shelves plans for e-voting
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
- A voter running a client other than the official client
- A vote being altered in transit
- Any form of evidence about how I voted
- A vote being read by any unauthorised party
- 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