[I think that among most voting experts, there is general
consensus on a lot of things like a) we're not ready
for remote online voting any time soon (with
some disagreement from some of the vendors),
b) punch cards are a big problem, and c) whatever
technolgoy we do adopt has to have adequate audit
trails. I think there is some disagreement about when
and if Internet voting from polling sites should be pursued,
and the suitability of DRE systems. Peter Neumann
and Rebecca Mercuri have been outspoken against the
use of currently available DRE systems (see Neumann's
note, which I forwarded ysterday
http://www.egroups.com/message/e-lection/245).
Their views are based on many years of research in this area.
However, other well-qualified experts take a somewhat
different view. I am forwarding below the views of
David Jefferson and Michael Shamos on DRE systems.
For the paper Shamos references in
his comments, see
http://www.cpsr.org/conferences/cfp93/shamos.html --LFC]


From: <jefferson@...>
To: "Lorrie Cranor" <lorrie@...>
Sent: Monday, December 11, 2000 2:52 AM
Subject: Re: Perspective on election processes Risks Digest 21.13

The following represents my personal opinions, and not that of my employer
or any other organizations I am associated with. Also, I must disclose
that my employer, Compaq Computer Corp., holds an equity stake in the
Internet voting company VoteHere.net; but that fact has no effect on my
opinions.

I have only recently become familiar with Peter Neumann's and Rebecca
Mercuri's position on voting systems, and I agree with much of what they
argue. In particular, I second their strong objection to proprietary
software in public election systems, their strong concern about many
possible
modes of insider fraud, and their worries about the security of any system
attached to the Internet.

However, I understand they may be opposed to almost any all-electronic
voting systems. Although I am a strong advocate of reliability and security
in voting systems, I do not go that far; I believe that DRE systems can
in principle be excellent replacements for current paper-based and punched
card systems. (But I have not studied the architecture of the particular
DRE systems enough to suggest that any currently marketed system is
adequate.)

I'll make divide my comments into the following dimensions:


Accuracy

Accuracy (in the sense of recording the voters' true intent) is where
I think DRE systems shine. It is the biggest reason, in the light of
Florida, why I think the country will move in this direction (whether
we security people like it or not, I might add.) DRE systems cannot record
any kind of ambiguous vote (requiring human interpretation); and they
would be programmed not to permit overvotes, and to warn voters of
undervotes
before the ballot is committed.

It is, of course, still possible to offer a confusing ballot layout to
voters on the screen, but this is true of all modes of voting. So, assuming
reliability and security of the device is satisfactory, I think that
computerized voting machines are the nearest to perfect accuracy we are
ever likely to achieve.


Reliability

DRE systems need power, so there is an obvious failure mode. They must
have nonvolatile, all-electronic memory, and they should have battery
power, or battery backup, sufficient to complete a vote transaction in
case power is interrupted in the midst of committing a vote transaction.
(But I don't like relying on batteries as the primary power source for
the foreseeable future.)

There must be procedures in place to deal with the case of machine failure
while a voter is using it, i.e. the voter should vote again on another
machine, and precaution taken that this does not cause a double vote to
be counted. But if voters are permitted to vote at any site in their county,
rather than only at their local precinct, and if voting lasts for days
instead of one day, and if there are multiple voting machines at each
location, then it would take a lengthy regional power outage to seriously
compromise an election. For locations where power is unavailable, then
paper systems should be retained.

Touchscreens and their drivers have reliability problems also, and one
has to be concerned about testing, calibration, and quality control with
them; however, they have proven solidly reliable in the banking business.

I believe that with any electronic voting system, the entire precinct
should be able to function with no moving parts, i.e. no printers, no
disks, no mice, no fans, etc., that can become reliability choke points.
And there must be no single point of electronic failure at a precinct;
there must not only be redundant voting machines, but any other associated
hardware, such as computers used to authenticate voter registration, must
also be redundant.

Other modes of *undetected* failure, such as flash memory error, are,
in my opinion, so unlikely that they are not worth worrying about on the
scale of other concerns. I am satisfied that the voting system as a whole
can be more reliable with DREs than with other systems.


Software engineering

These are perhaps the most difficult issues for all computerized voting
systems, including DRE systems. There is not enough space here to discuss
all of the problems and threats, so I will just list buzzwords: bugs;
Trojan horse code; security flaws; software version control; ballot
configuration management; proprietary vs. open code; specification;
documentation; testing; audit trail; certification standards; voting system
certification.

Strong demonstration (convincing to a skeptic) that a software system
has ANY particular safety, or correctness, or performance, or reliability,
or security property, is usually beyond our technical ability. But I
believe that a combination of good engineering techniques and special
properties of the DRE software problem can offer sufficient confidence
in the software base on DRE machines.

The special properties of the problem are all related to the fact that
DRE software should not be very complex (as these things go). It need
not involve a full operating system, since a voting machine is a
special-purpose device. It should not involve complex graphics, nor
real-time software, nor numerical software, nor concurrent, multithreaded,
or multitasked software, nor asynchronous devices, nor complex resource
management, nor networking, nor most of the other software paradigms that
contribute greater than average complexity. It does not even have to
be high performance. Hence, virtually all software engineering metrics
can be traded in the direction of extreme design simplicity, and that
contributes strongly to our ability to manage the software development,
testing, and certification, and have confidence in the result.

DRE system DO involve cryptographic software and key management however,
about which more later. So that is the one exception to the general
comments
of the last paagraph about how simple and low-tech they can be.

My approach to DRE system standards would be to REQUIRE simplicity in
as many dimensions as possible. I would require cryptographic software
to be off-the-shelf from recognized, published, widely-vetted, standardized
code bases--absolutely no vendor-grown security algorithms. I would require
DREs to be designed using only ROM and write-once storage, with no
read-write
secondary storage at all. (See auditability discussion below.)
And I would also require ALL software to be non-proprietary, even to the
point of published source. The code can be copyrighted and patented,
but I believe it should NOT be secret. To the extent that this allows
foreign companies that don't respect i.p. to pirate it, so be it.

This approach is our best protection against most software errors, and
in my opinion, can be sufficient. Remember, we have complex canvass systems
at the county seats that are considerably more complex that what I am
suggesting for DRE systems, and no one I know of suggests that we do without
them. The integrity of the election depends on that software too, and
it would seem to me perverse to allow complex back-end software systems
but disallow much simpler (as I envision them) front-end systems.


Privacy and Security

In a precinct situation voter privacy on DREs is not difficult to protect.
Most of the structure needed to protect privacy is a consequence of laws
requiring that the voter must enter the voting booth alone, and cannot
exit with any proof of how s/he voted. Of course, DRE systems accumulate
votes during the day, including perhaps audit information sufficient to
prove which voters used which machine. Hence, randomization techniques
should be used to prevent using knowledge of the approximate time or order
of voting to associate a voter with his/her vote; but this is not hard.

Security of voting on DRE systems is a combination of registration and
precinct procedures (voter authentication, human procedures to guard against
insider fraud) and DRE software (assuring that each voter is presented
the correct ballot, preventing votes from being lost accidentally, or
lost through fraud undetectably, preventing phony votes from being inserted,
preventing double voting, etc.) The software security features are a
combination of cryptography, key management, and electronic audit trails.
This is a lengthy subject, but is made manageble by that facts that (1)
cryptographic and key management systems sufficient for the very limited
problem of DRE voting are relatively straightforward, and (2) similar
procedures are needed for analogous security problems with paper ballots
are well understood.

On the other hand, there is a big new training burden on election officials
who understand the issues in election security deeply but are usually
not yet very computationally savvy.


Auditability

DRE systems must retain an audit trail sufficient to allow analysis of
any problem or election challenge, without compromising voter privacy.
They should also allow for more than one way to "count" the votes, so
that the second way might reasonably be called a "recount". The audit
trail, for example, could be a detailed trace of the I/O to and from the
touchscreen, so that everything presented to voters, and input by them,
is recorded at a very low level. This would include every action the
voter took, e.g. touched that missed an on-screen button, touches where
the voter changed his/her mind by pressing different buttons, etc. A
recount could be a program to reprocess this trace to ascertain a second
time what the votes were. The details depend a great deal on the detailed
architecture of the system.

However this is done, I suggested above that DRE systems should be built
without any read-write secondary storage. All of their secondary storage
for storing votes AND the audit information, should be non-volatile,
write-once memory. That way, it becomes impossible for any bug, or security
flaw, or deliberate action to erase either votes or the audit trail.


Transparency, understandability, voter acceptance

A final concern is that of the extent to which voters will understand
and accept DRE systems. At the moment the surveys of voters that use
them indicate that they like them very much. However, there has yet to
be a major contest of a DRE election, and it remains to be seen how recounts
will be accepted and how courts will view the lack of any original
paper record of the balloting.

Another concern has to do with the right of the public and the political
parties to observe the conduct of the election and the counting of the
ballots. What becomes of that right when the ballots themselves are
insubstantial microscopic fields in the center of a chip? Will watching
technicians put flash modules from a voting machine into a flash reader
and then typing some commands on a nearby keyboard be considered to satisfy
the right of "observation". There is not only no chad, but no punch card
either! Personally, I have no problem with this; but there is also a
significant minority of the American public that believes that all voting
systems are rigged, and hence all-electronic voting systems might be simply
construed as a more efficient way of rigging them.



From: "Michael I Shamos" <shamos+@...>
To: "Lorrie Cranor" <lorrie@...>
Sent: Monday, December 11, 2000 8:07 AM
Subject: DRE Challenge

My views on DRE haven't changed since my "Electronic Voting -
Evaluating the Threat" paper in 1993. In fact, since then I have seen some
really excellent ones. It is easy to dream up nightmare scenarios in which
voting machines can be tampered with. The question is how to do this so
the intrusion cannot be detected in pre- and post-election testing as well
as testing while the election is in progress. My point was that we always
get to a level where the risk is acceptable. Can I tamper with the
instruments of an airplane so it will crash even though the plane passes
pre-flight instrument checks? Sure, but then why do people keep flying?
Here's my challenge: I pick a DRE system. My challengers get
physical custody of it for a month. The challengers set up a sample
election but get a chance to modify the system to count votes incorrectly
and undetectably. I get the system back for two days, during which I can
look at whatever I want and perform any tests I want. If I detect that
they have modified the system to count incorrectly, they lose. We then run
an election in which I don't get to see how the voters actually voted
except through the system's own records and reports. After the election I
get two days to audit the results, using only the system's own audit
trail. If the count is incorrect and I can detect that from the system's
records, they lose. If they fool me into believing the incorrect results
are correct, they win. If they lose, I get $5000 and their apology. If
they win, they get $10,000 and I retire from the voting system
certification business. All the foregoing to occur before December 31,
2001.
None of what I say here applies to Internet voting, where the
risks are much greater.
You may publish the above to whomever it may concern but let them
put up or you know what. Despite the generous time frames allowed in
challenge, I expect it will not take more than five minutes to detect the
modification. However, I anticipate that my challenge will generate plenty
of heated responses but no actual takers. It is much easier to hypothesize
about risks than actually create them.



=====================================================================
This message was distributed through the e-lection mailing list.
For info and archives see http://www.research.att.com/~lorrie/voting/
=====================================================================