Re: confused about COTS vs open hardware

From: Joseph Lorenzo Hall <joehall_at_pobox_dot_com>
Date: Wed Feb 07 2007 - 17:02:28 CST

I'm not sure how to respond. Ben, you make great points. I guess the
essential kicker is does the OVC allow closed COTS products
indefinitely. Of course, having access to source code or verifiable
hardware is only one part of the security milieu. It's one place that
making inroads into now seems like a low-hanging piece of fruit
(especially given that there are companies that have stated that they
would comply or are building disclosable voting systems). This is
obviously not a simple subject and a lot of the data is non-existent
(cost data, etc.). It would seem that the OVC should try and attack
this from a systems approach... I'm not sure how to do that and not
make it an unwieldy task. -Joe

On 2/7/07, 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.
> -Ben
> _______________________________________________
> OVC-discuss mailing list

Joseph Lorenzo Hall
PhD Student, UC Berkeley, School of Information
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:12 2007

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