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

Colm MacCarthaigh colm at stdlib.net
Mon Oct 24 14:59:42 IST 2005

On Mon, Oct 24, 2005 at 10:53:49PM +1000, Craig Burton wrote:
> 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. 

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

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

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

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

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

Colm MacCárthaigh                        Public Key: colm+pgp at stdlib.net

More information about the E-voting mailing list