Re: confused about COTS vs open hardware

From: Ben Adida <ben_at_eecs_dot_harvard_dot_edu>
Date: Wed Feb 07 2007 - 16:07:48 CST

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.

-Ben
_______________________________________________
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:12 2007

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