Re: Re: Reply to Rons' Q's on TLV (Ron Crane)

From: Ron Crane <voting_at_lastland_dot_net>
Date: Wed May 18 2005 - 16:27:10 CDT

On May 18, 2005, at 1:16 PM, David Webber ((XML)) wrote:

> Ron,
> The model here is the OASIS TC process itself, underpinning
> the developer forum. We have three high profile ones running
> right now - one is the ebXML registry, the next is the
> ebXML messaging server (Hermes), and then the jCAM
> content handler toolset. All three are using SourceForge
> for code management.
> In each case the developer community is following the spec'
> then providing feedback and enhancements. The lead time
> is usually about 3 to 6 months between be release of the spec'
> and the implementation to support it.
> OASIS has a fully open public comment and input mechanism
> for user communities to guide the specifications and
> implementations - managed thru the Kavi portal system
> and archives.

This, combined with the appropriate cryptographic signature process and
hardware inspections, would then be the primary guarantor of security.

> The initial development would be Java based, but Python or
> others would be considered - depending on demand.
> Definately open platform.

What about the OS? There's plenty of room to hide malware (or malware
loaders) in there. Also the Java environment isn't open source, IIRC.

> As to issues loading - I'm assuming the hardware is
> delivered to the State or the integrator clean - not to
> the developer. Then the machine that
> has been configured and certified with the software
> components installed,

This includes appropriately checking the cryptographic signature(s)?
And hardware inspection?

> is used as the master - a cut made
> from that - and then that is mastered over on to each
> machine (using product like Ghost) and the machine
> sealed at that point.

It's not out of the question for Ghost (commercial, right?) to
introduce malware. It'd be better to use an open source duplication

> So the software is an
> exact copy on each machine, etc. If you are using
> a USB connection for all this and to the printer -
> then in theory someone could plug into that
> maliciously. My suggest would be to install a
> port monitor to log all services and activity on that.

Not a bad idea.

> Since the developer is not involved in this process
> at all - pretty tough to fake or tweak things. I think
> that also is a big change from today - where the one
> company is doing everything so easy for them to
> cheat.

It's pretty hard for the developers to cheat assuming all the proper
procedures are followed. Basically I'm looking at this exchange as a
way of helping to spell them out. This will benefit both OASIS and OVC.

>> 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?
> Because we're using a standard UI engine like XForms or Adobe PDF -
> not some vendor supplied engine. Therefore - again the control is
> through the scripts - and you will download and install the standard
> forms package. And you can inspect the scripting code as needed.

I'm not completely clear on this. Are you saying that the vendor writes
*no* UI code at all -- that the UI is entirely off-the-shelf? Or that
the vendor does write some, but pledges that what it writes is
completely open source? What's the procedure for verifying that? Who
does it? Or, for that matter, who verifies that the vendor doesn't
surreptitiously add some code to the off-the-shelf UI?

>> 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.
> The security I'm seeing is that of providing a physical source of
> voting information that is not in a digital format - and provides
> a correlation source of data. Notice also that casting ballot
> paper has lots of other good side effects in voter privacy,
> clear intent, and physical access (the computer cannot
> walk a piece of paper across a room) to the ballot box.
> This appears to me to be self-evident - I'm tired of reading
> academic studies that just seem to be jobs-for-the-boys
> to justify a thesis here and one there (errr, you're not an
> academic are you!?!)...

The VVPAT has some good attributes. I think all e-casting systems
should support it. *But* I also think its security benefits often are
oversold. That's why I keep asking about studies on its effectiveness.
And no, I'm not an academic, nor am I looking for thesis grist. I am
looking for evidence of effectiveness. It seems to me that both OASIS
and OVC derive most of their security from open source procedures and
hardware inspection, not from VVPAT.

>> 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?
> Clear this has to be OSI - and if there's one area I'd
> want to devote most time to testing and scrunity its here!
> Again - simple, simple, and simple. All records fed
> to it are in EML 440 XML format, along with EML 460
> and then it generates EML 480s and 510s. Those 510's
> are then read by another simple display XML stylesheet
> and that's what you see!

Yes. This area, and the UI, need the most scrutiny, because they both
are single points of failure.

>> But what if it's fraud? What procedures do you
>> recommend for handling it?
> There's basically two types of fraud detectable, and
> undetectable. In our case - if they managed to get
> a ballotID into the electoral roll tracking that then
> the voting system then puts into the electronic 440
> records, and then someone walks a paper
> equivalent into the ballot box - darn they are good!
> That's three levels of collusion - and a physical
> event - without someone saying - hey - didn't I
> just see your twin brother?

This isn't quite what I mean. I'm talking about a presentation fraud at
the casting station, or whatever you call the device that presents
choices, accepts voter input, and prints a ballot. The presentation
fraud could be perpetrated by either the vendor (if there's any slip-up
in the security procedures) or, much less easily, by a hacker. In any
case, the casting station can misrepresent the choices in a variety of
ways, thus either influencing the voter to vote how it wants, or simply
recording what it wants and depending upon the voter not verifying her
ballot. (This is why I keep harping on studies about VVPAT's
effectiveness.) Either fraud satisfies the system's redundant checks by
producing a fraudulent vote at the origin.

> Each "pillar of trust" needs to be protected with
> its own gatekeepers - no surprises there.


> Otherwise - if you have records and paper
> ballots showing up that do not match your
> guard criteria - then you definately want to
> investigate their source and trace back from
> there! The election officials are going to have
> to decide to call the election or not depending
> on the level detected and the type of attack
> used - and other external factors - like the
> candidates themselves - exit polls, etc.
> I think those are fairly clear who the
> authorities and their roles are already
> spelled out. you'd definately want to lock
> down machines in suspected precincts.

I think it'd improve the system greatly to recommend procedures for
handling this kind of thing. Most elections officials (and most
legislators!) do not understand computer security very well. In
particular, they might miss the implications of certain kinds of
malfunctions, and might well attribute real frauds (or serious system
failures) to "glitches", and thus basically ignore them.

> What we are providing is the means to
> diagnose, audit and analysize. We can hardly
> predict the attack itself.

But you can (to a significant degree), and should. Lest you think I'm
singling you out, so should OVC. (Eek! I just probably made work for


OVC discuss mailing lists
Send requests to subscribe or unsubscribe to
= 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