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

Brian O'Byrne bobyrne at statesoft.ie
Fri Oct 28 10:58:07 IST 2005


Craig,

Thanks for the information. I'll read the reports you mentioned.

On Friday 28 October 2005 05:40, Craig Burton wrote:
> Brian, I haven't tried to defend our system against the efficacy of
> the attacks you propose.  Some attacks, however, might not render
> valuable results and I discuss these.  I suggest others.  I noted
> and have removed the other tests you suggest as the mail is long.

This is exactly the point I wanted to stress Craig. You are proposing 
a system that has not been fully tested. I propose that it cannot be 
fully tested without giving people free reign to try imaginative and 
unexpected attacks.
I believe you will be reluctant to run some of these attacks because 
you cannot predict or detect their impact on the election. That is 
exactly why the system should not be accepted.

If and when this system goes live you will have people attempting all 
the attacks I suggested, and many others that neither of us have 
imagined. If you cannot predict or detect the results of the attacks 
you know about, how can you possibly have confidence the system will 
withstand attacks you don't know about?

[much cutting]

> Consider also that we need a random minority of voters to check
> signatures, not all.  We do have the ability to instruct voters to
> do this via the paper voting information (as opposed to relying on
> voters vigilance alone).   So the attack would have to have a
> significant, measurable effect.

I'm not sure how to read this, but if I was feeling uncharitable I 
could infer that you are willing to accept an immeasurable effect. 
That scares me because 'measurable' and 'significant' are not related 
in any way. An effect can be undetectable (thus immeasurable) while 
being very significant.

I'm not sure whether I mentioned this before, but I believe this leads 
to an easy DoS against the REV channel.
You say that only a small minority of voters will have to be vigilant 
enough to notice a trojan. What happens when that small minority 
reports a problem? Is the channel stopped?
If it is not stopped entirely then you cannot be sure which votes 
arriving from the channel have been compromised, leaving the election 
result in doubt.
If it is stopped then in order to stop the channel all I need do is 
report a problem. An instant, easy, DoS.

This is an example of an attack that someone looking purely at the 
technology will never see. You have to look at the system as a whole.

Of course (except for honeypots) there is a way an attacker could get 
an e-voting trojan on many machines with minimal chance of detection. 
Simply target those machines that are already part of a botnet. Since 
they are already on a botnet the chances of the owner noticing 
another piece of malware are near nil.
I can even target such machines by geographic region, since broadband 
providers tend to allocate IP blocks to regions.

[cut]

> There are common parts of the applet that are re-used with the
> following considerations:
> 1. we change the applet code frequently as part of maintenance
> 2. we have used an "obfuscator" on the compiled java bytecodes.
> This approach changes the applet bytecodes.  The reasons for this
> that the applet is smaller afterward; the obfuscator replaces
> variable names with noise so the bytecodes cannot be exactly
> predicted from the source (which breaks an attempted bytecode
> trojan or a trojan listening for a certain sequence of bytecodes in
> the JVM) and decompiling renders very messy code.  The obvious
> disadvantages of this are that it breaks the option to compare the
> published applet with another compile of the source, and we have to
> trust the obfuscator.

An obfuscator provides very little protection against a determined 
hacker. Given the ability of tools like Eclipse to rename methods and 
highlight code problems you can give readable names to methods and 
other members of a class very quickly. Obfuscation raises the bar, 
but only very slightly.

> Attackers should try to trojan a JVM.
> Attackers should try to trojan a PC and then to try a window
> overlay on the voting application.

I think you overestimate the amount of work involved in creating a 
hack for the JVM that would allow an attacker to read votes on the 
client.

> The hard aspect of this is estimating the likelihood of any attack
> being successful in an ongoing way, and that the attack has a
> significant impact on the result.   The tests are made harder to
> execute and measure by the fact that they would  be executed in a
> real election.  Schneier describes how something approximating a
> real bomb was put in real luggage as a test of baggage security,
> then they lost that bag.  We would have to defend testing against
> examples like that.

Interesting problem! ;)

> I would like to see these tests done.  I'd hope it would be part of
> a virtuous cycle of improvement, which is the point of technology
> pilots.

I'm not happy about seeing my ballot used in a pilot where one of the 
goals is to learn how the voting system is broken.

Any time I have seen a technology pilot it has been at least one of:
- A green-fields project
- Non-critical
- Backed up by an existing trusted system.

Voting is not a green-fields project, it is entirely critical, and we 
have spoken about the problems of parallel testing. Therefore I think 
the standards I'd accept in a technology pilot do not apply.

I'd love to come up with a solution, only because I believe whether I 
like it or not some form of electronically-supported voting is 
inevitable and I'd prefer to and shape it into something I can trust 
rather than fighting for a doomed prohibition.

The problem is that I expect a high standard before I can trust the 
system. It must be able to defeat (or at the very minimum detect and 
measure) all of the attacks I can think of and all the attacks that 
an intelligent, determined and resourceful attacker might mount.
... and I will fight for prohibition rather than accept something 
untrustworthy.

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