Re: draft of text for new OVC-sponsored bill

From: Ronald Crane <voting_at_lastland_dot_net>
Date: Tue Jan 27 2009 - 14:57:55 CST
Edward Cherlin wrote:
On Mon, Jan 26, 2009 at 6:24 PM, Ronald Crane <> wrote:

[sigh] I guess I have to break my own rule.

Ron, you are straining at gnats while swallowing camels (in
particular, in your other recent posts, the notions that hand-marked
paper ballots can be made secure, or are in any way preferable to
machine-marked ballots). We have evidently failed to communicate
something essential to you, but I can't imagine where the gap lies.

Thank you for the calumny on hand-marked paper ballots. I am sure it will enlighten all who listen. Also, I appreciate the personal insult; I was feeling too happy.

I don't think that great detail [in the class certification statute and/or regulations] is needed. There would be a minimum
standard for processor and memory, and there would be some
prohibitions, but I think that they can be summed up as "no external
access possible during voting" and "verifiable BIOS". Instead of
complicated design requirements, we can use relatively simple methods
for officials and observers to detect any problems, so that
problematic equipment just doesn't get used, or is immediately removed
from service on detection of a problem.
Unless the statute (or, more likely, the regulations promulgated under its authority) spell out quite precisely what is allowed, what isn't, how compliance is to be determined, by whom, and especially how it is to be enforced, any restrictions will be toothless.

I don't think this is necessary to go into detail about
at this point.  Mostly, it would be a set of dos and don'ts about how these
PCs can be set up, configured, and the procedures for how they are handled
before and after the election.
I think it's necessary to ban network interfaces in the statute. They're
hazardous, there's no good reason ever to have one in a voting machine, and
we won't always have an SoS as competent as Bowen to write the regulations.


o It is not necessary or desirable to ban network hardware. It is
necessary for our software to turn off any networking. This is not at
all difficult in Linux, regardless of the network hardware interface....
And what happens if the firmware is doctored to use the device, even if Linux thinks it's turned off? I'm not just talking your "verifiable [mainboard] BIOS" (which you have still to describe a plausible mechanism for verifying), but also the firmware in the network interface itself.
We have proposed the use of used government computers for voting. It
is extremely unlikely that any such computers will come without
network hardware.
Maybe the proposal needs modification to account for previously-undiscovered security risks.
o No network exploit can corrupt a CD.
It can corrupt the running OS and/or the running voting application, so it hardly matters whether it can corrupt a CD.
o The idea is to put the standards into the law, under the supervision
of a competent public standards body (choose from NIST, ANSI, ISO,
IEEE, but not ECMA), not of random SoSs. 
I'm sure SoSs will love this idea.
The law should also specify
public oversight, not control by partisan officials. Public oversight
can only be achieved by designed systems to be auditable, and then
requiring auditable data to be posted to the Internet. When the data
stream (software, ballot layouts, voting data) is public and
verifiable, it doesn't matter what can be done behind closed doors by
the devious and malicious, because it would be immediately detected.
The verification methods being proposed here for software and firmware leave open plenty of attack vectors, many of which are unlikely to be detected, and if detected, unlikely to be believed, and if believed, unlikely to be effectively remedied. For example, this next point:
o It will be easy to design systems for observers that can detect and
record any wireless network traffic going on at the polling place.
Forensic experts can then review this data. The software for these
functions already exists (war-driving, packet-sniffing). There should
be no active Wi-Fi access points in any voting facility. When wireless
becomes ubiquitous, we can discuss putting voting computers into
shielded enclosures. Basically these will be boxes with copper foil or
copper mesh sandwiched between layers of plastic or cardboard, or
something like that. Cheap, effective, and verifiable with common
equipment. (I wrote a study of the much more demanding Tempest
shielding issues long ago when it was much harder and more expensive
to accomplish.)
This is all just incorrect. I'm afraid that wireless communications became "ubiquitous" at least a decade ago. There's tons of wireless network traffic going on in every polling place. WiFi devices have ranges of hundreds of yards (ordinary WiFi) to miles (WiMAX). Cell phones (and computer cell network interfaces) have miles of range. Satellite phones (and computer satellite network interfaces) talk to satellites in geosynchronous orbit, 22,000 miles away. Broadband-over-powerlines is available in many areas. You will be unable even to record all that traffic, let alone to audit it in anything like the time frame needed to detect, interrupt, and back out an attack on an election. I doubt that even the NSA can do this.

Further, an attacker is likely to encrypt her attack data, making it extremely difficult to determine anything about its origin, purpose, or what might be listening to it.

That an individual can drive around freeloading off others' WiFi networks ("wardriving"), or that a corporate IT department can diagnose problems on its network using "packet sniffing" in no way supports the idea that you can effectively audit the wireless signals in any public space.


OVC-discuss mailing list
By sending email to the OVC-discuss list, you thereby agree to release the content of your posts to the Public Domain--with the exception of copyrighted material quoted according to fair use, including publicly archiving at
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
Received on Thu Jan 7 00:09:53 2010

This archive was generated by hypermail 2.1.8 : Thu Jan 07 2010 - 00:09:57 CST