How much open source is enough? Paranoia v MythBusters

From: David RR Webber \(XML\) <"David>
Date: Mon Feb 12 2007 - 09:00:57 CST

Clearly through my work with OASIS EML and OVS - my focus has been on
creating trusted open source software mechanisms.

Notice we have never had voting systems available that offer triple sets
of independently created auditable records of voting artifacts, all
created and stored to an open public standard, with source code that is
simple, clear and minimalistic in its logic.

For example OVS now has robust voter ballot logic for onscreen form
handling that runs to 100 lines of code TOTAL that runs in an open
source browser based form system. The key is using the XML standards
and leveraging the power of modern form handling tools to reduce the
code needed to the bare essentials.

What I am seeing emerging is what we had predicted - a stable set of
publically endorsable standards and accompanying software that is
community supported, open, proven and known.

Where does this leave us in terms of paranoia about the ability of a
system to cheat the ballot?

Key to good security is not just intrusion resistance - but also the
ability to detect intrusion with a high degree of probability. Just as
in banking systems - the highest deterrence is the certainty of being
detected. And internet firewalls provide the tools for engineers to
determine where and when an attack happened.

With the design of the OVS open source based on the EML specifications -
paper ballots - and having independent processes handling the ballot,
scanning and counting - to compromise this requires not just one attack
- but three - on separate and different systems. And that has to be
coordinated to prevent detection.

We have to ask the very serious question - when is enough open source
and open process here? This is the difference between theory and
practice - reality and speculation.

Clearly we have determined and NIST have agreed with these blue ribbon
criteria:

1) Paper ballots records are essential to provide independent
verification

2) Open source for the ballot handling and counting software essential

3) Use of open public standards to provide transparency

4) Multiple independently generated auditable sets of records and voting
artifacts (not just one set)

5) Ballot printing should be independently done from the voter ballot
handling (if computer based voting, rather than manual paper ballot)

6) Anonymous counting processes - initial counting is done without
revealing WHAT is being counted to the
   counting logic software - just anonymous choices - A1, A2, A2, B1,
B2, B3, etc. A subsequent control
   step then translates the grand totals into results that then
incorporates the candidate / resolution
   choice details. This is analogous to how SATs are scored - the
software counts bubble checks - and
   has no idea what the actual questions were or who the student is -
just an ID #.
   Again having open source allows you to verify that this is indeed how
the software is counting.

7) Control of the election ballots and choices is using open public
specifications and verifable by election officials - not hidden in
proprietary code. This relates back to 6) as well as the two
mechanisms are interlinked.

8) Ability to ensure that voter rights are enshrined in the voting
process and local legal requirements are met and attestable because of
the open public specification and standards in use.

You strive to keep this as clean and untainted as possible - by
separation of the information into descreet sets. When you do need to
expose some information - such as in partisan voting - or party
endorsing - this to localized to that step only. The OASIS EML
specification and standard does this extensively today.

So what about the hardware? The problem appears to be that people watch
shows like "24", and "Alias". Where they see bombs go off and engineers
remove hard drives and retrieve encrypted data and produce blue prints
of nuclear triggers in the space of 60 minutes from the ashes! We
really need MythBusters here to establish the difference between theory
- "Oh I can embed something in the hardware firmware - that cheats the
election" - and reality.

Reality is this - I'm developing the software, I have full access to the
systems, and I'm faced within the typical state and county election of
creating ballots for voters that have a couple of thousand variations
across districts and precincts - and get that all working - and I've
used 1) thru 8) above - so everything is certified - scrutinized -
tested with conformance suites and counting tests. Crucially also -
because of the OASIS EML approach - election officials control the
ballot - setup and independently verify the configuration. The
opportunities to compromise the voting has been reduced to those that
require colloboration between at least three or more separate
individuals entrusted with monitoring and controlling - and those
individuals need a highly sophisticated knowledge to avoid both detect
and having the software malfunction on election day.

Notice all attacks attributed to systems like Diebold are because they
completely fail to adher to 1) thru 8) - never mind the hardware
aspects!!!

At what point do you say enough already? An example here helps
illustrate this. Noone has yet that I've seen here discussed the
possibility that the electrical supply that the machines are connected
to - could be used to transmit signals that could manipulate the voting
process. Is this a real threat? Certainly Philips sells a home
telephone network system that apply demonstrates the capability. Where
are the MythBusters to debunk the theory that this is a viable attack
option - or do we just accept that this - along with firmware based
attacks are in theory possible - and that somehow having open source
for the formware is the total guarantee against this?

Fact is having open source for the firmware is - while nice and a
reassurance - is not much guarantee of anything at all. An analogue is
the medieval castle - the real defenses lay within the outer walls. Is
it nice to have a wider moat filled with water and based on rock so it
cannot be easily drained? Sure! But its not essential to the
operation of the castle. Is it more expensive to build a castle on
rock always - and does that restrict the castles you can build? You
bet it does! So in practice castles are designed to be erected on
every type of terrain.

In practice open trusted election systems have to be cost effective and
viable given public budgets and the will of the state legislators to
acquire them. We cannot afford the equivalent of a NASA Mars probe
funding and engineering effort every time we have an election.

I believe that given 1) through 8) - and explicitly avoiding custom
bespoke hardware - and instead selecting COTS hardware that is broadly
available and reasonably priced - (if it has open source firmware -
that's a nice to have - but not essential) - provides the correct level
of assurance here in practical election systems.

Again - those who advocate that firmware can somehow compromise ballot
systems - need to be able to demonstrate this actually happening - a la
MythBusters - with an off-the-shelf system from say HP or Dell - and
show how that will not also cause the system to then crash when someone
installs regular office applications and uses the system as normally
shipped to regular customers.

We would do well to remember that: "In theory, there is no difference
between theory and practice. But, in practice, there is." ~ Jan L. A.
van de Snepscheut

See the wikipedia entry - http://en.wikiquote.org/wiki/Theory

Thanks, DW

CTO OVS and member OASIS EML TC

"The way to be is to do" - Confucius (551-472 B.C.)

_______________________________________________
OVC-discuss mailing list
OVC-discuss@listman.sonic.net
http://lists.sonic.net/mailman/listinfo/ovc-discuss
==================================================================
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
==================================================================
Received on Wed Feb 28 23:17:15 2007

This archive was generated by hypermail 2.1.8 : Wed Feb 28 2007 - 23:17:27 CST