Security sub-project

From: David Mertz <voting-project_at_gnosis_dot_cx>
Date: Wed Nov 26 2003 - 23:53:11 CST

Amit Sahai <sahai@CS.Princeton.EDU> wrote:
|to propose that we initiate a process of dealing with security issues
|systematically (for the post-demo project).

I would be honored to have Dr. Sahai lead a full analysis of the threat
model and security issues that we need for production voting machines.
It looks like the NSF proposal has been delayed for administrative
reasons, so it would be valuable to get this work started among us
volunteers.

I know a bit about cryptography, and also a bit about the real world of
voting systems and voting laws, so believe I can be of some help here.
But hopefully we can also get some input during the process from the
real experts on concrete voting procedures like Doug Jones.

Do other members feel that it might be worthwhile to launch a new child
mailing list devoted specifically to these (post-demo) security issues?
I don't feel all that strongly, but the focus there does feel
sufficiently different to warrant it, to me.

Yours, David...

P.S. some more comments/annotations below:

------------------------------------------------------------------------
|(1) Outlining security concerns,
|(2) Proposing solutions,
|(3) Discussing Pros/Cons of suggested solutions.

These indeed seem like the proper aspects.

|Of course, proposed solutions need not be technical.

Specifically, many solutions must be guided by the legal frameworks of
the USA (or wherever else EVM2003-derived systems are used).

|I also suggest that when discussing cons, we stick to actual attacks,
|and not vague notions like "lack of simplicity".

I don't find this notion vague once it is connected to the very
important notion of *voter confidence*. It's not enough for a system to
satisfy professional cryptographers--it must also satisfy average
voters. These demands are certainly not always in conflict; but at
times they can be.

|I. Privacy/Anonymity Concerns
|II. Robustness Concerns
| A. Dealing with Hardware/Software Failures
| B. Dealing with other malicious attacks

I think (II)(B) might be divided further into: (1) Attacks on
transmitted data (ballots, etc); (2) Attacks on the system installation
process (i.e. insertion of trojans). But in general, this breakdown
seems right.

|Let me also put forward a "design philosophy". When a civil engineer
|suggests a bridge design, she does not suggest the simplest-to-build
|design that will hold exactly the expected load of the bridge. Instead,
|she has an ethical obligation to suggest a design that will withstand
|several times the expected load, even if it is more complicated.

I think the bridge analogy is somewhat misleading. Thicker metal isn't
really "more complicated." But more moving parts -does- typically mean
"more, possibly unanticipated, modes of failure." Adding cryptographic
layers and protocols seems much closer to "more moving parts" than to
"thicker girders"... at least in my mind.

Incidentally, Doug Jones and I (and a few others) had some discussion
earlier on the list about code verification/validation procedures and
the like. Certainly we did not raise any issues Dr. Sahai does not
know; but in a general way, these are known issues already.

--
---[ to our friends at TLAs (spread the word) ]--------------------------
Echelon North Korea Nazi cracking spy smuggle Columbia fissionable Stego
White Water strategic Clinton Delta Force militia TEMPEST Libya Mossad
---[ Postmodern Enterprises <mertz@gnosis.cx> ]--------------------------
==================================================================
= The content of this message, with the exception of any external 
= quotations under fair use, are released to the Public Domain    
==================================================================
Received on Sun Nov 30 23:17:10 2003

This archive was generated by hypermail 2.1.8 : Sun Nov 30 2003 - 23:17:13 CST