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

Craig Burton caburt at alphalink.com.au
Mon Oct 24 13:53:49 IST 2005


>>This relies on the hands being virtuous.
>>    
>>
>
>No it doesn't. Less hands means a lot less people to bribe, corrupt
>or whatever. It's that simple. More hands means more opportunity for
>oversight. This is basic security. 
>  
>
Basic security where?  Most security models limit who can touch or see 
what under what conditions.

>  
>
>>>You will need a clean compiler, a clean version of every library that
>>>compiler uses, a clean version of the kernel running the compiler, and
>>>clean version of the hardware running the compiler. And you'll need all
>>>of that all over again for the running binary. It is a complete waste of
>>>time.
>>>      
>>>
>>There are no absolutes; that's bad form. 
>>    
>>
>
>This however is an absolutele. It is trivial to prove the above with
>mathematical certainty. 
>  
>
Sorry, I don't follow.

>  
>
>>A hack has to work, it has to work silently and specifically and it has 
>>to not be detected.  It has to work in the presence of other software, 
>>it has to work on software that changes, it has to be developed, tested, 
>>successfully deployed, it has to wait till the right time.   
>>    
>>
>
>Maybe, that all depends on the full details of the scenario. 
>  
>
I'll say it does.  It matters absolutely : to write a hack that works 
perfectly, I need a clean compiler, clean BIOS, clean operating system 
etc etc etc.   Good security, according to Bruce Schneier and many 
others takes the position that we should assume the supporting 
infrastructure, the lines of communication etc ARE corrupted and are 
working against us.

Hackers will employ the law of least effort.  This helps us determine 
where to look for hacks.

>  
>
>>You imply ts a cakewalk to have whatever hack you can think of hidden
>>anywhere you can imagine on any machine anywhere. 
>>    
>>
>
>I do not imply this, at all.
>  
>
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?  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.

>  
>
>>That's simply impossible.   
>>    
>>
>
>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? 

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

>  
>
>>If this software process looks cumbersome, you haven't seen a 
>>Hare-Clarke recount with Robson Rotation (there are several permutations 
>>of the ballot layout) for 200,000 votes.  Actually, I haven't either, 
>>but it took a month.   That's enough.
>>    
>>
>
>That's an unrelated problem.
>  
>
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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.stdlib.net/pipermail/e-voting/attachments/20051024/cd9ae79a/attachment-0001.htm


More information about the E-voting mailing list