[E-voting] Testing REV systems. Was: UK shelves plans
bobyrne at statesoft.ie
Fri Oct 28 10:58:07 IST 2005
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
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?
> 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.
> 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
> 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
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
- 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
Brian O'Byrne, Statesoft Ltd.
Tel: +353 1 4100 993, +353 86 240 4719
More information about the E-voting