[Fwd: Re: [E-voting] About Estonian e-voting]
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
>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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the E-voting