Re: Is Open Source Enough?

From: Karl Auerbach <karl_at_cavebear_dot_com>
Date: Tue Sep 04 2007 - 20:27:25 CDT

Arthur Keller wrote:

Nice note. I generally agree with your point of view. But let me
elaborate a bit....

> I've been thinking about the role of open source in electronic voting
> systems. Here are some sketchy thoughts I'd like to share.
> 1. One of the crucial reasons for open source in voting systems is
> the ability for the public to inspect the machinery of voting
> systems. This concept is related to sunshine laws, public records
> acts, or the Freedom of Information Act. However, "published" source
> is sufficient for many of these purposes.

"Inspect" is a tricky word.

For example, Oracle lets people run performance benchmarks, but denies
them the ability to publish those results to others.

For purposes of increasing the trust in election systems, inspection
requires a right to publish.

Inspection, in the minds of many, tends to suggest a passive inspection.
  But we know that software is too complex for passive inspection. One
can easily stare for years at a piece of code and not notice issues that
are quite visible when that code is actually run.

And code is not everything; code requires a platform. And inspection
requires as much access to the platform as to the code.

I spend much of my time doing protocol testing. Good testing requires a
mindset that says "In addition to following the manufacturer's cookbook,
let's do it in a way that is different." Unfortunately the space of
doing things outside the cookbook is infinitely larger than the space of
doing it by the cookbook; thus conformance testing is conceivably
possible but full vulnerability testing is not.

Testing can be done ad hoc. But ad hoc methods give rise to
non-repeatability and disputes and plausible deniability on the part of

In light of these considerations I tend to subdivide the idea of
inspectability into component elements:

        1. The right to poke and prod the entire system to ones heart content
(without destruction of the equipment and for a finite time).

        2. To right to preserve the test harness and to fully publish (to
everyone) the tests and the test results without constraint from
non-disclosure agreements, use limitations, or copyright except to the
extent that any code publication may be constrained to only what is
necessary to illustrate a flaw.

        3. That others be afforded the ability to repeat the tests, subject to
some limitation on the financial and time risk of the vendor (i.e.
perhaps they might only need to have one system available for testing
and people who want to test would have to queue up. That tends to allow
the "scientology" form of blocking in which the machine is forever
checked out to vendor friendly reviewers, but that's a secondary level
of problem.)

One aspect that tends to be forgotten is a statement of some sort of

We all know that at some level a person with infinite resources and
infinite access to the equipment could bugger a voting machine. It is
important to create some sort of criteria about what we are worried
about and some reasonability constraints on how determined an attacker
we are concerned about or about the probability of accidental events.
(E.g. Memory media are always slightly flawed; we can reduce our
vulnerability to such flaws through the use of parity, ECC, checksums,
duplicate copies, crypto digests, etc, but we can never reduce the risk
to a perfect 0.)

> 3. While it would be useful for anyone to be able to publicly inspect
> voting system software...

Of course we should not forget Ken Thompson's ACM talk - - about how one might put
invisible Trojan horses into source code.

> 4. If we are to go through the trouble of replacing old electronic
> voting systems with new electronic voting systems run on open source,
> unless the new systems are designed to be secure based on a threat
> analysis model, the new systems may still have security
> vulnerabilities.

This is why criteria is so important. I spent 8 years building
multi-level secure systems and networks. Some of the work was formally
verified. Coming up with a criteria is hard. And it is a lot less fun
than sitting around thinking up threat scenarios.

But one thing that we are not mentioning is that it is not always
necessary to have an invulnerable system. It is often enough to know
that it has been attacked.

In the context of an election, such knowledge is valuable but what to do
about it is not obvious. Tossing the machine or the talley might be a
first-cut answer, but that opens the door to election manipulation via
selective attacks on precincts that are likely to favor the outcome not
desired by the attacker.

But at least knowing that something bad happened give us an opportunity
to stop the clock and consider what to do about the particular event
that transpired.

And how invulnerable to threads do we need to be? Should voting
machines be so immune to intentional incineration that their tallies
will survive someone burning down the precinct at the close of the
voting period?

I agree with you that threat/analysis is useful, as is a security
criteria. But a sense of what is reasonable and what is not should also
be articulated so that we can assess whether we are going overboard or
are not paranoid enough.

> 5. I would like to see ACCURATE develop threat analysis models in
> conjunction with a new voting system design team. Preferably, the
> system developed would be open source, or at least disclosed source.

I tend to use the word "disclosable" rather than "disclosed". I do not
believe it would be unreasonable for a voting machine vendor to say
something like "before the report is published, give us a chance, within
well defined time limits, to try to fix the bugs".

And let's be realistic, voting machine vendors have had their dose, a
big dose, of the consequences of hubris. In the future they are
probably going to be more cooperative and responsive; we should begin to
consider them as partners in getting things right rather than as
insatiable enemies. So given them a bit of slack and recognizing some
of their business concerns is not unreasonable.

We've got to remember that voting machines are not free - somebody
somewhere pays the costs. And good quality, documented code is time
consuming and expensive to write and test. ("Open source" is not a
guarantee of quality. And as one who daily works with open source, wow,
is open source frequently code of very poor quality or a decent idea
that is poorly expressed. [Paid source is sometimes not much better.]
And the idea that "Oh, there's a flaw, I'll just jump in and fix it"
rather forgets that not everyone is a decent forensic programmer or has
the time or inclination to exercise such talents.)

Personally I tend to agree with the approach of having a public, open,
disclosed reference platform, API's, exchange formats, and
implementation(s). But I would not equate the word "reference" with the
words "best", "optimal", "bug free", or "perfect".

And I think that there is a solid business model in the support and
maintenance of equipment built using the reference platform/code.

But better mousetraps are foreseeable, particularly as we obtain better
ways to adapt to the needs of voters with physical impairments, and we
ought not to so completely slam the door on the profit motive as to send
innovators elsewhere.

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 Sun Sep 30 23:17:05 2007

This archive was generated by hypermail 2.1.8 : Sun Sep 30 2007 - 23:17:20 CDT