Re: Reply to Rons' Q's on TLV

From: Ron Crane <voting_at_lastland_dot_net>
Date: Wed May 18 2005 - 12:08:24 CDT

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.

And for checking that it's really the same code via a widely-published
cryptographic signature. What about the open source development process
itself? Does it provide for the incorporation of all legitimate
publicly-suggested changes?

> 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.

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!"

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

> 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. The cheating
application can be loaded via a communications port or, barring that,
from an "unused" area of the hard drive.

> 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?

> 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!!!

The question is not really how to present the VVPAT ballot, 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.

> 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?

> 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.

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

-R

>
> ----- Original Message -----
> From: "Ron Crane" <voting@lastland.net>
> To: "David Webber (XML)" <david@drrw.info>; "Open Voting Consortium
> discussion list" <ovc-discuss@listman.sonic.net>
> Sent: Wednesday, May 18, 2005 10:33 AM
> Subject: Re: [OVC-discuss] Reply to Rons' Q's on TLV
>
>
>> On May 18, 2005, at 6:59 AM, David Webber ((XML)) wrote:
>>
>>> ...We're working at OASIS on putting together a component
>>> toolset around each of the key EML XML's - 440, 410,
>>> and so on. The idea is that implementers use the
>>> open source components
>>
>> I'm glad to hear about open source, and want to hear more. How do you
>> guarantee its integrity? That it actually ends up in the machines on
>> election day?
>>
>>> and then simply add their own
>>> localization logic and UI to that. So in the EU, that will
>>> be in Danish, Latvian, German, Italian, etc - and reflect
>>> local voting practice and traditions. Under the hood the
>>> open source components enforce the TLV processing
>>> and handling of the XML and associated counts,
>>> crosschecks, etc.
>>
>> And what guarantees that the UI for the voting station doesn't contain
>> code to perpetrate presentation frauds? Or the UI for the
>> reconciliation station to perpetrate tabulation frauds by presenting
>> the results -- that the OASIS code so carefully cross-checked --
>> differently from their true values? For that matter, if the UIs run on
>> the same hardware as the OASIS code, what prevents them from simply
>> overwriting it with their own code?
>>
>>> Voter verification and our friend Shamos - see my
>>> rebuttals to that piece of dubious "research":
>>> http://drrw.net/backup/Understanding%20VVPAT%20v%20VVAATT.pdf
>>
>> Hmm, that document talks about audio verification vs. visual
>> verification. Maybe you meant to point me to something else?
>>
>>> Basically - the printed ballot should be a self-evident
>>> summary - that even a 5th grader can verify at a glance.
>>>
>>> Not some "trick" SAT-style 5 choices - and which box did
>>> you check test - that runs into pages of tiny font text!?!
>>> I find Shamos work distasteful and insulting to voters - he also
>>> ignores basic work on human short-term memory and ability
>>> to do verification.
>>> Enough said - a well designed paper verification works.
>>
>> I've heard intimations that someone has have conducted a real study on
>> short-term use of VVPAT. Do you know anything about this? In any case,
>> we need more than a short-term study if we're going to entrust voter
>> verification with any significant responsibility for security. We need
>> to know whether it will "work" over the long term. Voting systems will
>> be used for decades, long after the original reasons for their
>> adoption
>> have faded from memory. They must continue to work securely even in
>> such an environment of reduced vigilance. [1]
>>
>>> Hardware inspections are something that could be done to bolster the
>>> process - and you would definately want to quarantine machines
>>> that the crosschecks showed issues with. However - notice that
>>> hacks and loaders have to surmount 4 barriers - they have to
>>> corrupt electoral roll tracking systems, and the voting system, and
>>> the ballot printing, and the counting system, all of which are
>>> separate on different devices, and open source.
>>
>> I don't think they do. They just need to corrupt the ballot casting
>> station so that it, for example, omits disfavored candidates
>> sometimes,
>> or makes their identifiers smaller or dimmer than those of favored
>> candidates, or their selection areas smaller or oddly-shaped, etc.
>> While these "presentation frauds" might not deter determined voters,
>> they're very likely to skew the choices of those -- and there are many
>> -- who decide how to vote only in the voting booth.
>>
>>> Prudence is still required however. You will notice that the
>>> OASIS EML is required to conform to the EU Council of Ministers
>>> recommendations on election management - and so that whole
>>> laundry list of physical checks and controls are inferred in TLV
>>> (online links to that are in the OASIS EML specs).
>>
>> I'll check that out.
>>
>>> As to systematic fraud - I have a few things on this.
>>>
>>> 1) TLV should allow you to gauge the scope and the
>>> frequency - so if each voting station has one or two
>>> occurences - then you can see a pattern that would
>>> be missed in a random audit. Since you are aiming
>>> for 100% crosschecking - even a small # of
>>> descrepancies would be cause to investigate further.
>>>
>>> 2) Deterrence - today hackers know they are most
>>> unlikely to be caught. With TLV a full audit trail is
>>> retained and 100% crosschecking is built-in so
>>> hackers run a very high risk.
>>>
>>> 3) Goof-ups do happen - so having three sets of
>>> counts helps diagnose this - and gives remediation
>>> options. Example - hardware failures, people
>>> inserting stuff in upside down - forgetting to
>>> enter a operator code, or switching the machine
>>> off by mistake, etc, etc. The idea is to provide
>>> election officials with options to solve these in
>>> a reasonable way.
>>
>> I like the 3 sets of records. But they don't prevent presentation
>> frauds at the casting station, nor tallying or presentation frauds at
>> the reconciliation station.
>>
>> -R
>>
>> [1] Also, please don't discount the problem of legalities: what would
>> actually happen were a voter to discover a mismatch? Would she just
>> get
>> to re-vote? Or does OASIS propose model legislation that would require
>> a full-scale investigation? What effect would that have on the
>> election
>> in which the mismatch was discovered?
>>
>>> Hope that answers your questions adequately.
>>>
>>> DW
>>>
>>>>
>>>> Having briefly examined the TLV approach, I have some observations.
>>>>
>>>> First, it seems to treat open source as an afterthought, and does
>>>> not
>>>> discuss how to guarantee that the publicly-reviewed software makes
>>>> it
>>>> into the voting machines on election day [1]. This makes the system
>>>> vulnerable to presentation frauds during vote casting, and frauds
>>>> during the comparison process. I don't see anything about random
>>>> manual
>>>> spot checks on the comparison process in the official docs, either,
>>>> though you seem to think they're acceptable (though not required).
>>>>
>>>> Second, it relies upon independent teams implementing various
>>>> portions
>>>> of the system, and, further, those teams staying truly independent
>>>> for
>>>> as long as the system is deployed. This doesn't account for the
>>>> forces
>>>> of consolidation (e.g., Diebold's acquisition of Global Election
>>>> Systems), nor for the regrettable fact that vigilance wanes over
>>>> time.
>>>>
>>>> Third, voter verification. While this is great for transparency, I
>>>> don't think that, over the long term, it'll do much for security.
>>>> Most
>>>> voters will not understand that verification is a critical element
>>>> of
>>>> the entire system's security. Rather, after a brief burst of
>>>> enthusiastic verifying, they'll come to view the system itself as
>>>> "secure", and verification as optional. [2] Of course this problem
>>>> affects OVC's system to a degree as well, but less than OASIS's,
>>>> because OVC's security rests more firmly on properly-implemented
>>>> open
>>>> source principles.
>>>>
>>>> Fourth, I didn't see anything about hardware inspections, which
>>>> makes
>>>> OASIS vulnerable to malware loaders in the casting and comparison
>>>> machines. (See the Shamos rebuttal OVC just published).
>>>>
>>>> -R
>>>>
>>>> [1] E.g., David Mertz's process described in our recent Shamos
>>>> paper.
>>>>
>>>> [2] Further, without a useful legal process to handle actual
>>>> mismatches
>>>> during verification, its effect is limited to correcting the votes
>>>> of
>>>> those who happen to find such mismatches, rather than correcting the
>>>> systemic fraud that may underlie those mismatches.
>>>>
>>>
>>> _______________________________________________
>>> OVC discuss mailing lists
>>> Send requests to subscribe or unsubscribe to
>>> arthur@openvotingconsortium.org
>>>
>>
>>
>
>

_______________________________________________
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:41 2005

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