[Fwd: Re: [E-voting] About Estonian e-voting]

Craig Burton caburt at alphalink.com.au
Tue Oct 25 06:07:52 IST 2005


>>Hackers will employ the law of least effort.  This helps us determine 
>> where to look for hacks.  
>
>Of all of your bizarre arguments, this is perhaps the most flawed. 
>  
>
A system bug or flaw can be anywhere.  A hack has a purpose and it can't 
do anything from anywhere on the machine.  A good search heuristic is to 
look where the hack can most likely be executed, be least likely to be 
found and yet most likely to achieve its purpose.  The BIOS is a good 
place to hide, but something has to call the BIOS code to get it 
executed after the boot sequence.  Better to trojan a common 
executable.  I could argue about microcode but this has even more 
constraints as a hack has to be prepared further in advance.

I assume you refer to a remote voter's PC here.  A machine that tallies 
votes can be better controlled and supervised. The tally machine or a 
DRE is more at risk than a home PC as the PC collects perhaps 5 votes 
and yet has to be found and infected from afar without tripping up a 
single boffin's firewall.

>  
>
>>Do you think it is as easy to write a piece of malware for a computer 
>>BIOS that can affect a specific action in a Java applet or would it be 
>>easier to write the same hack for the Java virtual machine?  
>>    
>>
>
>It would be relatively trivial to achieve either.
>  
>
Please provide examples or evidence that backs this assumption.  Both 
are very hard, the JVM possibly being more plausible.  There have been 
JVM trojans but I can't find an example of where the trojan waits for 
the specific bytecodes of a certain applet so as to affect different 
behaviour in the applet.  There was a trojan to perform gross changes in 
the MSJVM to break its security system.  In contrast, affecting a 
specific applet requires intervening in the JVM execution engine and 
waiting for a pattern in an applet, somewhat like the ACM compiler hack 
but with the encumbrance that the bytecodes cannot be known so long in 
advance as the stable "login" UNIX code.

Add to this the applet may be obfuscated before it is compiled so that 
the resulting binary is reduced in size.  To find the section of code we 
want to affect now requires reverse engineering a binary.  We also have 
to contend with the complex execution model of the JVM which performs 
checks and optimisations at run time that do not occur on physical 
hardware processors.  It has its own internal security system.

>  
>
>>Actually, I think a JVM trojan would be very hard to implement and I
>>struggle to find reports of this kind of attack in the wild, but a
>>BIOS attack to act on Java application?  Easier to go for the
>>windowing system, but then you have to implement an entire
>>faux-windowing system.
>>    
>>
>
>You think in far too narrow terms. It is very simple to fake input and
>output at both a the BIOS and JVM layer. But regardless, who is to say
>that they are trustworthy in the first place? Are you going to
>personally prove the correct operation of your BIOS and JVM?
>
>Malicious errors arn't the only thing we have to defend against.
>  
>
I haven't suggested that testing the JVM or the BIOS can prove they 
aren't hacked or busted.  We should assume we don't have a pristine 
platform to operate on.   The thing we rely on is the correct operation 
of the JVM in executing the bytecodes of a single-use applet.  It also 
has to correctly check the code signature if the user requests this. 

>  
>
>>>The problem is that it's not. It is categorically possible, and we
>>>must always ensure that we are protected against this possibility.
>>>Its improbability is outweighed the the impact of such a problem. 
>>>
>>>
>>>      
>>>
>>You assume the impact is pretty likely.  Do you assume that any impact
>>is immeasurable, and that there can be no contingencies? 
>>    
>>
>
>Those statements make no sense. Impact is measured by severity, not
>likelyhood. I do however know that one potential impact is an
>undetectable change in result, through manipulation of the input or
>record. I would class that as severe.
>  
>
I think you get my drift. I won't correct your English.

All EROs despise close elections.  No paper recounts are ever the same.  
There are all sorts of minor perturbations in the election process 
already.  A well written electronic system will actually remove this noise.

The risk of a significant, silent, successful hack is extremely low and 
it would require many other components and players to work just so.
There are things which can be done to detect or anticipate influence, 
there are far deeper audits available for electronic transactions (which 
don't break the Geneva Convention on free and open elections).  Also see 
my other mail about parallel testing. 
At worst, an electronic election can be re-run without many of the 
logistic constraints of paper election. 

>  
>
>>>>The real risks can be managed. 
>>>>
>>>>        
>>>>
>>>Absolutely, and VVAT is still the only convincing and practical
>>>risk-management strategy I've seen. 
>>>      
>>>
>>For DREs, and I assume you mean paper VVATs.  Sure, the machines are
>>too closed, too close to the providers.  The software is monolithic.
>>VVAT is a stop-gap, however.  The DRE systems need to be
>>re-implemented to include VVAT.
>>    
>>
>
>No, VVAT is only convincing and practica risk-management strategy I've
>seen. For any system, and it's no stop-gap. The laws of computation are
>not going to change. Neither are humans going to develop the
>perceptability to observe microscopic nano-second level phenomena. It's
>an end game.
>  
>
A voter-verified audit trail is a great strategy.  How it is implemented 
and where, sees it as either a stop-gap or a long term part of using 
electronic devices for voting.  At the moment, a printer attached to a 
Nedap voting machine is a stop-gap.

Still, this doesn't help remote voters: some sort of remote service for 
VVAT has to provide the equivalent oversight.

>  
>
>>It's why they built eVACs, a DRE voting application.  If you want a
>>really good election system (H-C+Robson) and you want it to scale,
>>some form of automation is going to be needed some time.  I hope the
>>world gives Hare-Clarke and ballot rotation a go and ditches FPP, but
>>they will need machines to make it possible.  It think it's possible.
>>    
>>
>
>Thankfully, we don't have FPP.
>  
>
If the US wasn't FPP, Kerry would have got Nader's votes and left (ish) 
majority would have won as they should have.   The ramifications of the 
US FPP voting system are global.

To convert the US or any democracy to a better system like STV or PR in 
this era will take at least some machines, somehow, somewhere.  The 
scale is too great and scale alone is a bad reason for elections to 
remain infrequent and unrepresentative.   I'm confident automation can 
help this system.

I have serious doubts, for better or worse, that the occasional, minimal 
paper election process and parliamentary/rep system will remain 
satisfactory channel for the public's contribution to public policy when 
Susie Doe from Smallville can contribute to a collaborative wiki on 
foreign policy or abortion read by millions of people.
I also know a Nedap/PowerVote machine is not appropriate for this era.  
I think Internet voting as it is, is not a good use of computers as the 
underlying premise (high stakes, minimal, infrequent ballots) are 
themselves fundamentally brittle. 

Best,
Craig.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.stdlib.net/pipermail/e-voting/attachments/20051025/b7889468/attachment.htm


More information about the E-voting mailing list