Designing a fraudulent DRE: paper 2 of 3

From: Steve Chessin <steve_dot_chessin_at_sun_dot_com>
Date: Fri Apr 30 2004 - 14:44:21 CDT

        How to design a virtually undetectable fraudulent DRE

This paper describes how to design a fraudulent voting machine that
evades detection by the Independent Testing Authorities and local logic
and accuracy tests.

We'll assume that the software in the machine only needs to rig the
elections for President, Governor, US Senate, and Congress (House of
Representatives), and only in the general election, not the primary.

Since the software can't know in advance the names of the candidates,
it will use the party affiliation of the candidates in determining
which votes to alter. (Since this information is displayed on the
screen to the voter, it is also available to the software.)

So the fraud won't be obvious, it will take, say, on average ten
percent of the votes for party X and give it to party Y. It will
display to the voter what they selected, but it will record it
internally the way it wants. This will only affect close races (55/45
and closer), but then that's the point. To give an election to one
party in a district (or state) that's safe for the other would arouse
suspicion. Shifting 10% of the votes should be sufficient. (It can
also take more votes from the minor parties - no one will notice.)

Since the source code will be shown to the testing authorities, the
"logic bomb" will be created using the techniques described by Unix
co-inventor Ken Thompson in his 1984 ACM Turing Award lecture so that
the logic bomb doesn't show up in the source code. (See
http://www.acm.org/classics/sep95 for the description.)

Since it needs to be honest when the elections officials and testing
authorities run the logic and accuracy tests, it won't actually alter
the ballots as they are cast, but it will wait until the machine is
"closed". If the machine is being closed at a reasonable closing time
(say, between 8pm and 8:30pm), and it was opened at a reasonable
opening time (say, between 6am and 7:30am), and it's the first Tuesday
after the first Monday in November in an even year, then it will go
back over all the stored ballots and rewrite ten percent of the votes
given to the "wrong" party. If it's not election day, or it's outside
normal election times, or the machine is being opened way late or
closed way early, it will assume that this isn't a real election and it
won't change any votes.

It will use a random-number generator, seeded by the machine-readable
serial number, to decide which, and what percentage, of the "wrong"
ballots to change. The reason for this will become clear further on.

The testing people may try to fool it by changing the date and time, so
it will have to detect this. The real-time clock (RTC) chip is set at
the factory using a manufacturing interface, not through the screen.
The testing authorities and the elections officials don't have access
to the manufacturing interface, so they have to use the screen
interface when they want to change the date or time. When they do so,
instead of changing what's in the RTC, the software will just store the
difference in a memory location, and take that into consideration when
displaying the time. For example, if it's noon on Monday, November
1st, 2004, and they set the date to 8am Tuesday, November 2nd, it will
put "20 hours" into the offset location, and add it to the RTC value
whenever it needs to display it. The logic bomb will only trigger if
the RTC says it's really election day and the offset value is zero (or
close to zero, since clocks do drift over time and they may want to
adjust it by a few minutes).

Just to make sure, before it alters any votes, the logic bomb will make
sure the votes haven't been cast in the typical logic-and-
accuracy-test pattern of one vote for each of the first selections, two
votes for each of the second selections, and so on. It will also check
for the "typical" voting pattern of a few voters in the morning, a
lunch-time surge, scattered voting in the afternoon, and an evening
rush, and only alter the votes if it is reasonably confident that this
is a real election and not an artificial test.

About the only way that this rigged software can be detected is by
setting aside some machines on election day and casting ballots on them
throughout the day using a pre-arranged script. The script will have
to include when to cast each ballot as well as how, since it has to
mimic an actual polling place. If the testers find a discrepancy, they'll
have to decide if it's the machine, or if they made a mistake in
following the script. If they test multiple machines with the
identical script, the use of a random-number generator will result in
different machines behaving in different ways, further confusing the
testers. And if they do decide it is the machine, what are they going
to do? The polls are closed! It is not likely that the courts will
immediately order a new election. They'll probably order more tests,
and on additional machines, and since the election will be over when
those tests are run, all the machines will work perfectly. Absent
hard evidence that the machines used on election day for the actual
ballots were malfunctioning, the election results will be accepted as
legitimate, even though they are fraudulent.

The only real way to defeat such a logic bomb is with a
voter-verified audit trail (or record). The machine can't print out
the altered votes, because the voter would notice. If the machine
prints out the true votes, but records internally the altered votes,
then the one-percent manual recount will spot the discrepancy. This
opportunity for committing large-scale voter fraud would be
eliminated.

[The author is a software engineer with over thirty years of experience
in the computer field. He currently works with hardware engineers who
are designing new machines, advising them in the areas of reliability,
availability, and serviceability (RAS). His area of expertise is the
interface between hardware and software, especially in the area of
injection, detection, correction, and prevention of hardware errors by
software.]

--Steve Chessin
1426 Lloyd Way, Mountain View, CA 94040
==================================================================
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
==================================================================
Received on Fri Apr 30 23:17:27 2004

This archive was generated by hypermail 2.1.8 : Fri Apr 30 2004 - 23:17:29 CDT