Re: Reply to Rons' Q's on TLV

From: Edward Cherlin <cherlin_at_pacbell_dot_net>
Date: Thu May 19 2005 - 07:32:51 CDT

Look at it this way. We have thought of the obvious hazards, and
we have a strategy for dealing with each of them in principle,
and a plan for carrying out that development program in detail
when we get to it. But we haven't done the full security audit
of election systems yet. We know that other hazards will be
identified, and we know that we will find measures for dealing
with them.

There is no such thing as perfect security, but it should be
possible to reduce risks to the point where the cost of cheating
is higher than the reward. If we find a risk we can't mitigate
by technical and procedural means, we'll have to go public with
it, and let the citizens decide what they want done about it.

The security of a voting system is in the system, not in the
individual parts of the system. Paper by itself is very
insecure, electronic voting by itself is even more insecure, but
the combination can be made much more secure than any system
ever used.

On Wednesday 18 May 2005 10:08, Ron Crane wrote:
> On May 18, 2005, at 9:12 AM, David Webber ((XML)) wrote:
> > Ron,
> >
> > OK - more answers here.
> >
> > My view on the open source solution is that the
> > county or state government is responsible for
> > installing the open source from the trusted certified
> > and approved copy / site.

We propose to have code run from CD-ROM, not using any software
on the computer's hard drive. We will have to require the use of
BIOS chips that we have scrutinized for malware and found clean,
and we will have to test the hardware to be sure that those are
the chips used.

> And for checking that it's really the same code via a
> widely-published cryptographic signature.

Right. With methods that ensure that we are really testing the
code, not just getting the expected answer back from some cheat.

> What about the open
> source development process itself? Does it provide for the
> incorporation of all legitimate publicly-suggested changes?

Short answer: Yes.

More detailed answer: Somebody has to be in charge of determining
what is legitimate. As far as possible, the criteria for
deciding will be made public, but there are always judgment
calls. There will, of course, be public debate on these
decisions, and there will, of course, be conspiracy-minded kooks
screaming to the heavens above when their pet obfuscation is
rejected. I speak from experience here. Apart from the kooks,
most projects are able to achieve consensus about the right
directions to take.

> > Since the goal here is to script *everything* with XML,
> > the configuration process should be:
> > 1) install open source
> > 2) install XML scripts that election officials have
> > either created or certified, or both, that control
> > presentation and voting choices, etc.
>
> Good.
>
> > 3) install any unique localization code - this would
> > most definately *not* replace the OSI code. If
> > changes are needed there - those must be done
> > thru the OSI project. The actually coding here
> > reason for it, etc, would have to be known
> > and justified. Most localization should be
> > possible thru 2) above.

*All* localization must be done through 2). The base code must be
correctly written for localization in this way, so that there
can never be a claim that type 3 code is necessary.

> I understand that the *purpose* of the localization code is
> not to replace the OSI code. But if the localization code's
> vendor were malicious, it *could* make it replace the OSI
> code, thus corrupting the system: "Ooo, time to load the
> special DLL!"

No it can't, because there isn't any "localization code". There
are only replacement text strings to substitute for other text
strings. Localization doesn't get to touch the code or its
security checks. There is no localization DLL. Just text.

> Speaking of DLLs and malicious code, what OSes does OSI
> specify?

This is a misunderstanding of the process. Free and Open Source
Software runs on everything, and nobody specifies what.

First you bootstrap the GNU C compiler's code generation module
to the new processor architecture, ending with cross-compiling
the C compiler on the old system to generate a version that will
work on the new system. For a new operating system, you rewrite
the base libraries. Then you recompile whatever you want that is
in C, including other compilers and interpreters, then you
recompile code in other languages, and then at last you can run
pretty much anything that fits on the new machine and doesn't
tie itself to any particular hardware or software.

Thus Linux is now routinely the first operating system available
for any new processor, since Mac doesn't get ported, and Windows
takes forever. Sometimes Linux is available for a new
architecture before the hardware is released, running in
emulation on some other system.

We have written our demo in Python, so it runs on Windows, Mac,
and Linux, and can be easily set up on other platforms.

> > 4) Post- election - random inspect machines to
> > ensure code not tampered with.
>
> This is pretty easy to subvert. A competent malicious vendor
> will restore the certified application at the close of
> polling, or upon any other event that suggests that an audit
> is about to occur.

You are assuming that we take no other countermeasures. Of course
we will include this possibility in any security audit.

> The cheating application can be loaded via
> a communications port or, barring that, from an "unused" area
> of the hard drive.

We are thinking of having the hard drives removed for voting,
since they will not be used. Wired communications ports will be
blocked, disabled, or removed during voting. We can easily
monitor wireless traffic in or near a polling place that uses
any of the published standards such as WiFi.

Now a cheater has to create a non-standard communications method,
get chips made for it, and get them into the hardware so that
nobody can detect them even when they are receiving. All this
while the voting officials are free to buy their hardware from
any certified vendor. Not entirely impossible, but severely
constrained, risky, and relatively expensive.

> > The XML scripts contain standard ballot layouts
> > and UI presentation details - that must conform to
> > EU regulations - so "cheats" on presentation should
> > be avoided - since the OSI will present the ballot
> > in the perscribed manner.
>
> How do you guarantee it will? Why couldn't the vendor subvert
> the UI code to do whatever *it* wants, instead of what's
> dictated by the XML scripts?

Can't. The UI code is built in, and is not changed by the ballot
layout designer. If the UI code were changed, the system would
fail the first security signature test.

> > On the subject of guidelines and VVPAT - we
> > definately need more guidelines - but basically
> > I view voting as yet-another-government-form-filling
> > exercise. There are standards for government forms,
> > and ensuring that information is clearly and unambiguously
> > presented - there is also a wealth of work - by likes of
> > HP, Microsoft, Apple, Adobe, et al - on how to do this
> > correctly. It's *not* rocket science!!!

Nevertheless, Florida managed to completely obfuscate the
butterfly ballot. The Gore-Lieberman line was not aligned with
any of the holes. However, on the computer, alignment can be
guaranteed.

> The question is not really how to present the VVPAT ballot,

It isn't a VVPAT in the OVC system. It's the ballot. It is best
not to mix the two terms, since they have legal meanings that
don't mesh.

> nor whether we should have one -- I think we should, since its
> transparency and relative immutability are important features.
> The question is whether the VVPAT adds any real security,
> either in the short or the long terms. If you know of any
> studies on this question, I'd love to hear about them.

We don't need studies. DREs are utterly untrustable. Why do you
doubt this?

Paper is not secure by itself. Auditability requires two separate
data paths diverging from each event of significance (here, the
casting of a vote; in double-entry bookkeeping, the debit and
credit records). We choose to accept an electronic path that
provides checks on the validity of the paper along with other
benefits, while the paper provides the essential checks on the
validity of the electronics.

> > BTW - did I mention that we're using off-the-shelf
> > hardware here - not any custom bespoke vendor stuff.
> > Should run on any PC type platform the State or County
> > has picked to use. There maybe some barebones hardware
> > requirements - no CD drive, no wireless, etc, sealed case,
> > but otherwise - its a stock machine and printer.
>
> There definitely need to be requirements on hardware: no
> concealed communication devices (not just no wireless, but no
> Bluetooth, no BPL, etc.) for one, no special vendor-provided
> firmware (e.g. BIOS) for another. And, of course, no internet
> connections, which easily can be used to load malware. In
> fact, network connections of any type raise red flags, since
> they extend each machine's security perimeter to the network's
> boundaries.
>
> > The three sets of records are designed to prevent tallying
> > fraud. Even if the scanning software has been compromised
> > - the OSI routines that count the electronic voting records
> > would have to be similarly tainted - but there exists no way
> > for the two pieces of software to communicate! And the
> > XML being used is rigorously checked to ensure the content
> > conforms to EML 440 XML - no "extra" data allowed.
>
> What about compromising the software that reconciles the three
> sets of records? Why couldn't it just report what it wants,
> instead of reporting the facts?

Because the data will be published, and anybody can run their own
reconciliation and their own checks of the digital signatures.

> > If mismatch is found - it could be legitimate - a spoiled
> > ballot for example - or a cancelled ballot. So you really
> > only want to count a vote where both paper and electronic
> > match. The idea is to keep this simple - so people can
> > re-vote easily with confidence - if something screws up.

Actually, there will be cases where only one or the other is
present and you do want to count it. Otherwise, voters could be
disenfranchised by stealing and destroying ballots. But once
things are this bad, the decision has to be made in public by an
election judge, after a thorough airing of the audit data and
other evidence.

> But what if it's fraud? What procedures do you recommend for
> handling it?

Tell it to the judge.

> -R

-- 
Edward Cherlin
Generalist & activist--Linux, languages, literacy and more
"A knot! Oh, do let me help to undo it!"
--Alice in Wonderland
http://cherlin.blogspot.com
_______________________________________________
OVC discuss mailing lists
Send requests to subscribe or unsubscribe to arthur@openvotingconsortium.org
==================================================================
= 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:42 2005

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