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

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


On Thursday 27 October 2005 12:42, Craig Burton wrote:
> 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.

Did these groups include or consult people with expertise in voting? 
(Perhaps Rebecca Mercuri or even some esteemed members of this and 
other citizen action groups). I presume they included people with 
information security expertise.
Were these groups given a broad remit (find a flaw, any flaw) or were 
they asked to test certain sections of the system?
If you ask such a group to look at the technology there is a strong 
chance they will miss attacks that can be effected physically or 
socially. The system as a whole must be open to attack, not just the 
technology.
Were the groups asked to work within a set of assumptions (eg: assume 
the voter is vigilant enough to read dialogs about certified code)?

> >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.

Am I right in suspecting that the applet is largely coded before the 
close of withdrawals, and that the embedded candidate information is 
a relatively small or self-contained piece? In this case the code 
from one election can be used to devise attacks on the next election.

> >- 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.

Perhaps. Or perhaps a successful attack is nothing more than getting a 
voter to use a client that could have been changed, or perhaps two 
records of the vote are made, one correct and one incorrect, or ...

> >- 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.

Perhaps. Or perhaps the vote collation is compromised, or ...

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

Yes.
The entire system must be open to this testing. Assume nothing.

> > 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?

Anything that might be reasonably accepted as evidence by someone 
attempting to buy or coerce votes. A PR/STV preference combination 
would be a good example.

> > - 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,

Perhaps the trojaned client I put on the voters machine sends two 
copies of the vote, one to the expected central server and one to me. 
Perhaps I have a way of recording the SSL conversation. Perhaps I 
have a camera trained on one of the public voting booths, or screen 
capture / keylogging capabilities, or ...

> > 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

Absolutely. Assume nothing.

> >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?

My point here is that there are ways for people to get malicious 
software onto voter's machines, but those ways are mostly illegal. So 
to test the vigilance of the voters or the efficacy of the code 
signing and private keys without doing anything illegal allow the 
official web server to send out a client prepared by the attackers 
once in a while instead of the correct client.

> >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.

There are details to be worked out... ;)
Perhaps the faux client would have to work in exactly the same way as 
the real client, except that it does not have the official signatures 
or access to the private keys. If any voter accepts the faux client 
and votes using it then we can conclude the signatures and keys are 
not effective.

> >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.

This is why the attacks included in the testing program will have to 
be monitored by election officials. Any attack can be stopped at any 
time (even before it is put into effect). But the only reason to stop 
an attack would be if you are not confident that the system will 
pass.

That is the point of this exercise Craig. I want to see people 
attacking this system in all manner of imaginative ways, because that 
is what will happen in real life. These attacks can be monitored and 
stopped at any time, even before the ballot begins. If an attack is 
stopped because the monitors suspect or fear it will disrupt the 
election or disenfranchise someone then the system has failed. The 
system passes only if the tests are allowed to run and the system 
defeats all of them.

> 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.

Absolutely, now you are getting into the spirit of it.

> 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.

Brian.
-- 
Brian O'Byrne, Statesoft Ltd.
Tel: +353 1 4100 993, +353 86 240 4719
http://www.statesoft.ie/




More information about the E-voting mailing list