Re: confused about COTS vs open hardware

From: Richard C. Johnson <dick_at_iwwco_dot_com>
Date: Thu Feb 08 2007 - 09:19:29 CST


The goal IS the main package. And, yes, we do improve security with each step we take towards a totally open voting system. Security is related to design as well as to "Openness", and it is not necessary to have the ultimate security in order to deter or prevent intrusions. I run Linux on my computer, not in the belief that it is absolutely safe from e-predators; it is not. Rather, I believe that it is a sensible move to improve the safety of my computing environment.

Taking a absolutist position may be fun, may tickle one's logical fancies, but it does not help solve some of the here and now real world problems we face. That is why I am keen to see Open Source code in voting systems. Not because it is absolutely safe; just because it is more transparent and harder to fox than the proprietary software we now enjoy. Recall Avi Rubin's comments on the Diebold code found naked; it is primarily bad code in addition to its exhibition of security holes.

I hope this helps to answer your question.

-- Dick

Ben Adida <> wrote: Joseph Lorenzo Hall wrote:
> I would argue that this is overstated. For example, if you allow
> third-party COTS components to remain closed, you at least know that a
> developer in the election software business isn't likely going to be
> able to corrupt the software.

This really seems like a false sense of security. Once the rules of the
game are set, you could easily have the malicious adversary build a COTS
product as a separate entity that isn't officially "in the election
software business."

You have to decide whether the scope includes a malicious adversary
willing to corrupt a US Federal Election. I think we all agree that we
*have* to consider such an adversary. Then, setting up a bogus company
to produce "mission-critical COTS software" that must be used by the
voting machine is very clearly a potential attack. Ignoring it is not
very different from giving current voting machine manufacturers the
benefit of the doubt.

> There are other things that you get
> from only allowing third-party COTS to be closed: their software
> development models and resources might be much more advanced and
> intense compared to voting system vendors, you get to use standards
> that might not have an as-now functioning open source implementation.

This is the classic anti-open-source argument, isn't it? I'm pretty sure
you're an open-source advocate, though :)

Even assuming your argument is right, you're now talking about security
against bugs, not security against a malicious adversary. Better
methods, better standards, more programmers, etc... doesn't give you
security against a malicious adversary if you can't see the whole code.

> There's probably more that I could think of. All this is to say that
> you do get some benefits from allowing voting systems manufacturers to
> use third-party closed source COTS software. I'm on the record as
> saying that there should be a deadline for even that to be phased out,
> but I believe that a step-function from development models that are
> closed and use third-party closed software to full disclosure is not
> good on a number of levels. -Joe

It may well be true that going to full disclosure right away is bad.
But that does not imply that partially good is beneficial.

If what you're talking about is a staged deployment: application code
must be open in 2007, operating system in 2008, drivers and microcode in
2009, then that's great, but it should be written that way in the OVC
plan. The goal has to be the whole package, and we can't fool ourselves
and think we've improved security until the very end. Not against
malicious adversaries.

OVC-discuss mailing list

OVC-discuss mailing list

= 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:13 2007

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