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

Craig Burton caburt at alphalink.com.au
Thu Oct 27 12:42:36 IST 2005


Brian,
Thanks for these. 
They up the ante, and I'll try to add value.
...

> 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.
>  
>
There is some evidence that "hacking comps" are discredited, but we 
would pay a retainer I suppose.
Qinetiq, Actica and Netcraft were hired to hack our system, Netcraft 
from inside the data centre.  Netcraft was paid by us, and they found a 
hole.  We fixed it and none of the others reported it.   None of these 
groups had a long lead time, only two weeks.

>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.
>  
>
They also get the source codes for the client application (which is a 
java applet).  But this can only be published after close of withdrawals 
as all candidate information is embedded in the applet.

>- 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 
>disenfranchised.
>  
>
So a successful hack changes a vote, then changes it back, for example, 
and this is recorded for evidence.

>- The definition of a successful test (demonstrating a failure) will 
>change on a case-by-case basis depending on the attack used but might 
>include:
> Integrity breaches:
> - A voter running a client other than the official client
>  
>
> - A vote being altered in transit
>  
>
More like, the voter is tricked in to using non-SSL connection, or an 
ISP has an SSL proxy or something.

By "in transit" you mean all the way from the voter's "confirmation" 
screen to the ERO's preferred counting software/printouts?

> Secrecy breaches:
> - Any form of evidence about how I voted
>  
>
You would have to back it up : you'd have to agree they knew something 
about you and your vote.  We'd have to use PR and you'd have to provide 
a hard-to-guess and unlikely preference combination.  What about 
something private from your PC?  Or does this fail to prove they were 
also able to affect your vote?

> - A vote being read by any unauthorised party
>  
>
Again the party also needs to prove the vote they read was real.  They 
need to produce a secret they found.  Long list of unlikely preferences, 
your authentication credentials,

> Count failures:
> - Any attack on the count process that affects the result
> Other:
> - DoS, personation, ...
>  
>
Possibly also stealing(?) ballot PIN numbers from delivery?  See
http://catless.ncl.ac.uk/Risks/24.08.html#subj14

>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. 
>
OK, I misunderstood you.  The "client" goes out to the voter and runs in 
their browser.  Here you mean the hackers are allowed to run their own 
programme on the server or the hackers are given indefinite root access?

>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. 
>
Okay, so we let the attackers provide a faux client for download for the 
voter?  I'm not sure how this can be done in the course of a real 
election.  Do you just want to see one voter download the fake client 
and try to vote?  This would not be good enough evidence, we'd need 
piles of people to be fooled, but then its too late.

>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 
>data.
>
>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.
>  
>
Is integrity the only challenge?  I personally think that 
disenfranchisement is a greater risk for REV.  But this is harder to 
test as a successful effort to interrupt the system will lead to real, 
well, disenfranchisement.  I guess if a hacker can show they can block 
up the system for a minute at will, the vulnerability could be seen to 
allow indefinite interruption.

There might be other attacks against the "secure printer" or voter 
credential delivery mechanism, against the certificate verification / 
revocation service (Thawte) for the voting client and the server SSL 
service. 

All the tests are valid and should be done.  I will try to have them 
done, I can't pay the testers so I have to oblige the Electoral 
Commission, a university or the ODPM to pay, if the next pilot is in the UK.

Thanks again,
Craig.



More information about the E-voting mailing list