Re: Optical scan computers shown vulnerable

From: charlie strauss <cems_at_earthlink_dot_net>
Date: Tue May 31 2005 - 18:53:11 CDT

I dont know if I'd go so far as to say its sinister. Just to play the devils' advocate I'll suggest two (quite lame) situations where a programmer might think that calling code on the card was a good idea.

if the card were the ballot description card as well as the vote storage card, the code might be code that was required to interpret some novel image format used in the display of the ballot.

if the card were the vote storage card perhaps the card alos contains an algorithm used to encode the data stored on it rather than placing this in firmware on the machine itself.

These of course are not sufficiently justifiable reasons to call executable code on something that most people would expect should be an inert obejct.

It's not unprecendented. smart credit cards and smart RFID tags also can execute programs in response to queries. But in this case the processor is part of the credit card or tag. it is not running in the memory space of the polling unit's CPU. That would be viewed as asnine from a security standpoint.

I guess the closest analogy to this sort of stupidity are the imbeciles that try to do secure website input validation on the client computer rather than the server. duh!

-----Original Message-----
From: Jim March <>
Sent: May 31, 2005 4:14 PM
To: Open Voting Consortium discussion list <>
Subject: Re: [OVC-discuss] Optical scan computers shown vulnerable

To me, one of the key things Bev is pointing out here is that the
documented and supposedly "certified" known code inside the Opscan
firmware is "calling" any available code on the memory card, whatever it
may be.

This speaks of a very deliberate plot versus "security hole".

Bev knows there's a June 16th deadline looming for the VSPP is and will
have much more technical detail out by then or at that meeting.


Charlie Strauss wrote:

> While it wont truly surprise anyone here, Bev harris's crew recently
> demonstrated a design vulnerability in Diebold's optical scan computers.
> 1954/5921.html
> It's a seriously dumbed down breathy explanation. As I read it in a
> nutshell, diebold's removable vote storage memory cards, which have a
> high level physcial access, contain executables that get called
> directly by the main program. Moreover these executable are
> unencrypted and undergo no validation before being called.
> They showed that for example there were not even program length or
> checksums to validate the stored procedures.
> they showed that infact the stored executable could alter the vote
> totals and produce
> 1) perfect "zero" tapes
> 2) perfect total sums
> 3) shift an arbitrary number of votes from one candidate to another
> 4) do so without any diagnostics catching the switch.
> 5) pass logic and accuracy tests.
> One of course still needs physical access, but this considerably
> lowers the barrier and most importantly enables the dreaded software-
> injection-after-candidates-are-known threat.
> Why do people think it's a good idea to use fonts, graphics and now
> memory storage formats that allow code execution? It's not like one
> needs that sort of flexibility in a voting system. All the
> executables should either live in one single defensible place or if
> distributed then at least act as objects that don't allow each other
> to modify their protected data.
> In other news intel is finally making computers that can do hardware
> validation of the signed software for the entire boot process. I
> strongly recommend that OVC only use such hardware.
> _______________________________________________
> OVC discuss mailing lists
> Send requests to subscribe or unsubscribe to

OVC discuss mailing lists
Send requests to subscribe or unsubscribe to

OVC discuss mailing lists
Send requests to subscribe or unsubscribe to
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
Received on Tue May 31 23:17:50 2005

This archive was generated by hypermail 2.1.8 : Tue May 31 2005 - 23:17:53 CDT