Subject: Re: internet voting -- ICANN, SmartInitiatives, etc.

From: Ed Gerck <[email-masked]>
Date: Fri, 12 Jan 2001 20:37:14 -0800

[long, but worth every megabyte]

>From: "Stephen Sprunk" <[email-masked]>
>
>Throwing encryption at voting is not enough to solve algorithmic
>problems.  Digital signatures violate ballot secrecy and provide no
>protection against most forms of fraud.

No. Digital signatures such as X.509/PKIX do violate voter privacy, but 
never ballot secrecy.

In all fairness to you, maybe there is a confusion with the word "privacy".
In this case, maybe you write "secrecy" above but you mean "privacy". BIG 
DIFFERENCE, though.

Now, my affirmation (and it does NOT depend on implementation) is that 
Safevote's system uses digital certificates (the DVC) and yet provides 
fail-safe, absolute protection for voter privacy -- simply because to
use the DVC the voter never discloses any identifying information 
(name, address, etc.) in order to be strongly authenticated in our system.

In other words, with the DVC technology even if *everything* fails, 
*everyone* colludes, there is a court order, still there is no way that we or 
anyone else can link a voter to a vote.  And yet, we can strongly (in mathematical 
terms) link a voter with the right to vote, with the correct ballot style 
to be used by that voter and with the vote cast by that voter -- as well
as a series of non-repudiation and verifiability proofs in support of auditing.

The DVC technology is described in our documentation made public
(eg, at http://www.safevote.com/aboutus.htm) and in The Bell newsletter,
December edition, copy available at http://www.thebell.net/archives/thebell1.8.pdf
in the article on fail-safe voter privacy

>
>The de facto (and in some places legislated) standard for electronic
>voting security is the absentee paper ballot. 

No. The standard is the FEC standard. Period.

> Aside from technical
>details, both have the same fundamental problems:
>
>o  Ballots are subject to coercion, theft, and sale.
>o  The voter may not know if the balloting medium is compromised.
>o  A voter can sign an affidavit and vote again at the polls.
>o  Ballot secrecy can be broken by government conspiracy.

You forgot tampering and other problems. However these are not
the most important sources of fraud, in many cases.  Fraudulent
or mistaken voter registration is, often, the single most important
source of problems.

>
>All of these fraud methods are already available today, and it is
>possible to design an electronic voting system which introduces no new
>methods.  

No. The use of an electronic voting system introduces software
fraud as a new fraud method.  There are others, such as virus,
weak password compromise, etc. 

>It is also possible to make the first three reversible after
>detection, which can't be done with paper ballots now.

No, again. "Reversible after detection" buys you nothing, because
a good fraud is one which is not detected.  In any case, in case
of detected fraud, there is always the recourse of a new election.

>
>Schneier's _Applied Cryptography_ is a good place to start reading up on
>secure elections. 

If you want just a one-sided theoretical view of some aspects of voting.

Voting is much more complex than most people (and cryptographers)
imagine. And, it needs to keep this complexity. For example, with many
ballot styles, diverse rules for ballot rotation, provisional ballots, logic and
accuracy tests, etc. For example, it is not enough to authenticate the voter, you
must also ofentimes authenticate information that depends where the voter
lives (encoded in the ballot sytle) -- for example, what school board to vote to.

I believe Schneier also needs to rethink his attribute list for voting, as well 
as his vision that multiple "translation steps" would make errors increase. It is
desirable in voting systems that no one could be, at the same time, jury, 
judge and executioner.  Dividing tasks into stages is important to
deter collusion, provide auditing trails and allow for the famous "need to
know" principle to be applied.

When you work with election systems for some time, you also begin to
appreciate that open-loop solutions do not work.  Printing a piece of paper,
expensive at it is, does not provide for closed-loop verification of even
simple attributes, for example -- whether the voter received the correct
ballot style approved to that voter.  Besides, you run the danger that one
voter may disrupt the system  -- he may declare that the paper does not
correspond to his vote, while it does.  So, you need a third system, and so on.
The solution is to allow for multiple channels of trust, and this is why
printing *one* piece of paper simply does not cut it.

Voting is also very much like an iceberg -- most of it is hidden from you, until
it hits you.

In a conventional voting system, the process of registering voters and producing
voters lists and/or voter credentials often accounts for more than fifty percent of
the overall cost for administering elections. Harry Neufeld, "The Range of Advanced
Technologies Available for Election Organizations," Let's Talk About Elections, ed.
Carl W. Dundas (London: Commonwealth Secretariat, May 1997).  Thus, an
improvement towards automation of the process may have a considerable effect in
the industry, provided that the requirements for privacy and security are met.
Similar considerations can be made regarding conventional methods of electronic
voting, where a communication network or the Internet is used for some or all of
the communication exchange

I also take exception with some people's use of Roger Needham's affirmation that 
automation as replacing what works with something that almost works, but is faster 
and cheaper.  As a lead designer of Computer Numerical Control Systems for 10
years, with much of that experience including closed-loop control directly
applicable to network voting, I would say that automation is providing that
which is humanly impossible -- providing perfection, almost all the time, over
and over again.  We do not even need to recall the election case in Nassau
County, Fla. We, humans, hate repetitive jobs. But we do excel is finding errors.

So, a network voting system can well use humans for real-time auditing and
recounting.  Verifiability, including voter verifiability, can considerably reduce the
probability of undetected fraud. For example, if 10,000 voters cast their ballots in an
election where the probability of frauds, attacks or faults leading to the loss of any
voted ballot is at most 5% and if only 300 voters do verify whether their respective
ballots were received, then the probability that the loss of at least one ballot will
not be detected (and thus the fraud, attack or fault will not be discovered)
is less than 0.1%. This exemplifies the use of a small number of closed loops
(300) in order to leverage security by a factor of 50x for 10,000 voters (reducing
undetected frauds, attacks and faults from at most 5% to at most 0.1%). Thus,
verifiability is important for example to foster public trust in Internet voting by
allowing one to close the loop of trust –  i.e., trust, but verify.

How about requirements?

A set of 16 strict standards for precinct-based Internet voting – which are
technology-independent and can also be applied to paper-based and electronic
touch-screen systems – was recently presented by Safevote for public comments at
the Internet Voting Technology Alliance (www.ivta.org ), after a round of comments
by experts and online discussion groups. The requirements include specifications for
voter privacy, vote secrecy, election integrity, tamper-proof ballots, open protocol
review, open source code, technology independence, physical recounts, multiple
audit trails, and 100 percent vote accuracy.

The requirements and background can be downloaded at
www.thebell.net/archives/thebell1.7.pdf . To allow independent use of the requirements
as a public standard, they can be licensed at no cost also for commercial applications.
A demo of a precinct-based Internet voting system implementing the requirements is
available at www.safevote.com/demo2000/.

Of course, security cannot be proven by any amount of tests. The objective of an open attack
test such as the one performed by Safevote at Martinez, CA,  must be to find problems, not to
prove that problems do not exist. These are completely different viewpoints.  However, the
absence of both theoretically successful attacks as well as practical attacks during an
extended period of time in a high-visibility open test with full attack assistance and clear
attack feedback suggests that the technology used does offer a noticeable security increase
over a typical e-commerce system.

Safevote's open attack test described at www.safevote.com/tech.htm showed that the
following attacks were 100% forestalled during the entire test for 24 hours a day in 5 days:
(1) Denial-of-Service; (2)  Large Packet Ping; (3) Buffer Overrun; (4) TCP SYN Flood;
(5) IP Spoofing; (6) TCP Sequence Number; (7) IP Fragmentation; (8) Network Penetration;
and other network-based attacks.

These are hard facts, that no one desiring to "prove" that Internet voting is unsafe
should ignore or take lightly.

"Security is only as strong as its weakest link" is the paradigm. The paradigm shift
is that security can be made as strong as we desire.  And, it is not so new.  Hindus
in the Mogul period some 500 years ago already knew it (The Bell, October, Interview).

Cheers,

Ed Gerck

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Sat, 13 Jan 2001 09:17:40 -0800

Ed, why do you insist on advertising your patent-pending voting 
solution on the IETF mailing list? It does not involve any IETF 
protocol work, does it?

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Ed Gerck <[email-masked]>
Date: Sat, 13 Jan 2001 10:20:09 -0800

> solution on the IETF mailing list? It does not involve any IETF

;-) SMTP, HTML, TLS, PGP, and others, including TCP/IP.

Pls do not be so bent out of shape by the word "patent".  I think we
have a fair proposal for it, which we call FREE patent, and is much the
same as FREE software.

However, I respect your disagreement.  Hope we can meet some day.

Cheers,

Ed Gerck

---

From: [email-masked] (Kai Henningsen)
Date: 13 Jan 2001 21:14:00 +0200

> In this case, maybe you write "secrecy" above but you mean "privacy". BIG

Indeed. The way you have it defined, both are one half of what must be  
achieved (impossible to identify voters, and impossible to identify  
votes), with both halves completely meaningless in isolation (which is why  
a traditional paper vote does achieve the combination, but neither half in  
isolation). Whereas the way most people define this, the two terms are two  
names for the same thing, which is the whole (it must be impossible to  
determine who voted what). The correlation is the problem, not the  
isolated facts.

There is more obfuscation like that in your "16 requirements". Not what  
I'd consider a recommendation.

> Safevote's open attack test described at www.safevote.com/tech.htm showed
> that the following attacks were 100% forestalled during the entire test for
> 24 hours a day in 5 days: (1) Denial-of-Service; (2)  Large Packet Ping; (3)
> Buffer Overrun; (4) TCP SYN Flood; (5) IP Spoofing; (6) TCP Sequence Number;
> (7) IP Fragmentation; (8) Network Penetration; and other network-based
> attacks.

Grand. It withstood network level attacks. That's about the most  
meaningless test possible - all it proves is the quality of the TCP stack,  
it tells absolutely bloody nothing about the voting system itself.

Which in itself tells us something, and it's not a compliment.

MfG Kai

---

From: Ed Gerck <[email-masked]>
Date: Sat, 13 Jan 2001 15:28:35 -0800

> I'd consider a recommendation.

Unless we define and isolate the concepts used, it is nearly impossible to meaningfully
deal with them. This is basic scientific method.  Thus, making a clear distinction
between "secrecy" and "privacy", as well as between "identification" and
"authentication" and "non-repudiation" is at the heart of the matter here. Doing
otherwise is obfuscation -- "to make obscure."

> it tells absolutely bloody nothing about the voting system itself.

Forestalling  Denial-of-Service attacks was unheard of and called "impossible"
in Internet voting until we showed how it could be done in one specific network
configuration useful for elections in precincts.  There are other configurations
where it can be done as well, as we shall show in the future.  This was one
Holy Grail in Internet elections, and we got it.

The same applies to other 7 attack types mentioned -- so this was no easy feat
for 5 days, 24 hours/day attacks, with full disclosure and a help line.

Conclusion of the test: "Internet" does not mean "insecurity".  Just because
it uses the Internet it does not mean it MUST be insecure.  Contrary to lore,
Internet communications can be made arbitrarily safe and reliable
(Shannon) if you take into account all the systems connected to it.

The first step is to recognize that any communication channel has a boundary,
which is quite arbitrary. By properly recognizing the sub-communication channels
inside a boundary and by properly placing such boundaries, the point I make is
that it is possible to have the communication system (roughly):

registration --> voter --> ballot box -- > tally --> report

as error-free, anonymous and secret as anyone else may wish (Shannon).
Here, the systems connected to an Internet-base channel are not ignored.
They are taken into account and with adequate error-correction channel(s)
(Shannon).

Again, this is a lot easier in the praxis for precinct-based Internet voting.
Which is all we are talking about at this time.  Home/office-based Internet
voting is IMO too political to be meaningfully discussed at this time. Even
though we do have the technological answer for remote voting as well, we
would lose too much time in discussing it now.  Rather, we prefer to focus on
precinct-based solutions, at a fraction of the price of DREs (electronic
voting) and with better assurances.

Cheers,

Ed Gerck

---

From: Ed Gerck <[email-masked]>
Date: Sat, 13 Jan 2001 17:48:11 -0800

Paul:

In the interest of dialogue, I wish to remind you that this thread started yesterday
when someone asked what was the IETF doing on voting protocols.  Going further
back, almost one year ago when the IVTA was to be founded to -- quess what --
discuss Internet protocols (as the Internet Voting Technology Alliance), I sent
the following email to this list:

/////////
List:

                  Announcement ivta.org

Internet voting is a case where privacy must be protected, so that
arguments to justify losing voter privacy in the good name of security
are simply not possible.  Which  firmly posits security  as a protection
of privacy -- not as an enemy of privacy -- in the problem-solving
assumptions to be considered.

In this context, an international team of experts and companies are calling for
open discussions on Internet voting technology.  A public founding
assembly will take place February 28 in Washington D.C. at 9 a.m.

Details at http://www.ivta.org
/////////

In the discussion that followed, it was clear that the collective mind of the IETF
did not want to develop Internet protocols and that the IVTA was a good move
to take such subject elsewhere, to an application-specific forum.  Of course,
this was all before Florida, when "chad" was likely to be seen as a misspelling
for something else.

So, there is a forum already for discussing Internet voting protocols -- it is the
IVTA. The tech list charter is archived at http://www.ivta.org/tech/charter.txt and
the archives are at http://www.mail-archive.com/[email-masked]/

Needless to say, the IVTA was founded based on some ideas from the IETF,
including open peer review as a mechanism of choice for defining Internet
protocols and the idea of favoring consensus building ove rmajority decisions.

Cheers,

Ed Gerck

Ed Gerck wrote:

> -

---

From: Jon Crowcroft <[email-masked]>
Date: Sun, 14 Jan 2001 12:47:48 +0000

the bggest problems with security ssytems are generally 90% to do with
design errors at level 10 (human, not policitcal, economic,
application, transport etc)

it would be interestign to run a _real_ experiment in 3 types of
voting (comuter based, networked computer based and traiditional) and
see if the results came out the same - it should persist for several
decades before one could believe that any adaption in the
democratic process hd factored in human behavioural bias .... imho

 >>voting) and with better assurances.

 cheers

   jon

---

From: Ed Gerck <[email-masked]>
Date: Sun, 14 Jan 2001 10:24:01 -0800

> application, transport etc)

Explorers of any kind oftentimes are led to believe in monsters at the
"end of the sea", but not all of them and so they move forward.
Security experts today are divided in two camps. Those many that
believe we can never make anything secure and those few that
believe we can make a system be as close to perfect security as
desired.

> democratic process hd factored in human behavioural bias .... imho

This would make sense in a statistical approach based on frequency
of events, where we need many events and even then we are never
sure because we did not run an infinite number of tests.

So, what you suggest is bound to fail, as a practical matter.

Instead, we follow a two-track approach using real-time auditing
built into the protocol in a secure zero-knowledge formalism so that
auditing during voting neither tampers nor learns anything from the
voting process (keys, votes, voter identities, msgs, etc.), and the
Bayes approach to statistics, also used by Shannon, where we
deal with conditional probabilities in multiple channels of
information.

In other words, Safevote's protocol provides a neutral observer that
goes undetected by all machines (and software) and yet allows
all processes pertaining to that observer to be recorded,
followed in real-time and fully verified against 100% trusted
(yes, such a thing exists and there are many practical ways
to do it in elections) records of what it should be.

Thus, trust on the election system is earned as anyone
can see that the system does exactly what is expected, for a
random message, any  number N of times.  By increasing N,
we decrease the probability that an error can occur in N+1,
N+2, etc.  Key to this method is that it must be fully undetectable
by the system, so that the system has no way of knowing
whether it is facing a voter or an observer in auditing.

There are other auting processes that must be enabled as well
and, in fact, auditing must be built-in into the entire system
from voter registration to ballot reporting by means of closed
loops of trust (not to be confused with closed loops of
authorization).

Cheers,

Ed Gerck