Re: code validation? - rom based attacks

From: Ron Crane <voting_at_lastland_dot_net>
Date: Wed Feb 23 2005 - 14:18:37 CST

This would mean forgoing the security benefits of open source software
and falling back upon the second level of security provided by VVPAT.
As I see it, our only choice to maintain the benefits of open source is
to make the machines ourselves. Even certifying a vendor's machines
would leave open too many cheating avenues.

As for a ROM cheat at the voting station, it might not twiddle the
totals directly, or it might twiddle them in a way that attempts to
avoid the effects of VVPAT. An example of the former would be
occasionally presenting the favored candidate first, or occasionally
omitting disfavored candidates from the selections, or presenting the
favored candidate in slightly bolder text than the disfavored ones, or
making the favored candidate's selection area larger than the others
(!), etc. Since these kinds of cheats affect the casting of the vote,
but not the production of the ballot, VVPAT won't catch them. Testing
might uncover these cheats if they're not craftily contrived to occur
only during an election. An example of twiddling the results to attempt
to avoid the effects of VVPAT would be monitoring the rate of voting,
and cheating only when the polling place is busy (and, thus, when
voters are less likely to verify their ballots). The code could also
refrain from cheating for a time when it senses that a cheat has been
discovered, to create the illusion that the cheat was "just a glitch".

Of course there's still the problem that no one (to my knowledge) has
so far demonstrated that enough voters will verify their ballots to
catch cheating, nor have I seen a proposal for a legal process that
effectively redresses an election in which voters discover such

I'll look at the PKI thing.


> Audit, Audit, Audit.
> If the totals arew changed, you have to go back to the Voter Verified
> Paper Audit Trail.
> You have to statistically validate the tabulation from the VVPAT, to
> detect malicious or
> accidental vote changes.
> See prior note about using PKI web of trust/delegation of authority to
> provide round trip
> audit log "proof" of correctness.
> On Wed, 23 Feb 2005 11:00:11 -0800, Ron Crane <>
> wrote:
>>>>> There's a problem here. There must be a known set of vendors who
>>>>> have earned trust via the review process you described. Let's
>>>>> posit that OVC is the only such vendor initially
>>>> Nah... OVC is more like a certifying standards body. Voting is
>>>> very decentralized in the USA, and it's almost certain to be a lot
>>>> of different vendors in different locales. Think of us like OASIS,
>>>> IEEE, or W3C: we might provide a reference implementation--and
>>>> vendors might even use our code (probably should do so to insure
>>>> code quality and auditing)--but vendors can compete for a
>>>> particular service contract.
>>>> But certainly qualifying as a vendor of Public Software should be
>>>> subject to laws (some OVC'ers are working on this in various
>>>> states).
>> There's another, more insidious problem with OVC not being the sole
>> vendor. That is, since elections officials will demand turn-key
>> systems, vendors will provide hardware. It would be easy for a vendor
>> to include a ROM in its hardware containing a cheating version of the
>> software. The hardware easily could pretend to boot from the CD
>> containing the verified software, and the cheating software could
>> perform except for the cheating exactly as if it were the
>> verified software. If the hardware had, say, wireless networking
>> capability, the timing and nature of the cheating could even be
>> controlled remotely [1].
>> Even if OVC were to enter the business of certifying voting machines
>> produced using its code, it would be hard-pressed to detect this kind
>> of cheating. A vendor could supply OVC with non-cheating machines to
>> test. And even if it didn't, black-box tests of a cheating machine
>> would be vanishingly unlikely to discover the cheating.
>> -Ron
>> [1] Long-distance WIFI is coming soon to a computer near you.
>> .
>> _______________________________________________
>> OVC discuss mailing lists
>> Send requests to subscribe or unsubscribe to
> --
> Keith Copenhagen
> _______________________________________________
> 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 Sun Feb 27 17:17:12 2005

This archive was generated by hypermail 2.1.8 : Sun Feb 27 2005 - 17:17:13 CST