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

Craig Burton caburt at alphalink.com.au
Sat Oct 29 12:29:21 IST 2005


Brian,
I'll be able to reply to this next week.  I can say from skimming below 
that the tests one can run are open ended and so the product would 
always seem incompletely tested.  Also, it was used in a pilot and there 
is some risk in doing this.  Using the system in a non-binding election 
or a cold run introduces risks that whatever survives the fake election 
fails a real one.  I don't think it is impossible to run non-invasive 
tests in a binding pilot, it's just not a cinch.
Let me get to this when I can, your points careful are well put,
Best,
Craig.

Brian O'Byrne wrote:

>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.
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.stdlib.net/pipermail/e-voting/attachments/20051029/c3e80cd9/attachment.html


More information about the E-voting mailing list