-----BEGIN PGP SIGNED MESSAGE-----
Thanks everyone for the helpful comments. I've combined them as well
as I could. Some folks sent privately, as indicated.
David Honig wrote:
>
> At 01:03 PM 1/25/01 -0500, William Allen Simpson wrote:
> >I've been working with Congresswoman Lynn Rivers on language for
> >electronic ballots. My intent is to specify the security sensitive
> >information, and encourage widespread implementation in a competitive
> >environment. We'd like feedback.
>
> You should list the desirable properties of a voting system and
> then the threats to those properties.
Actually, there's a lot of this already, going back many years. There
were many such threats described on this list last year, and there have
been a couple of conferences. In the process of passing legislation,
somebody might make a presentation to a committee, or write a report on
a specific protocol. But, that kind of information isn't specified in
an "authorization" statute.
"Arnold G. Reinhold" wrote:
> I find it unsatisfactory to review a proposed cryptosystem
> design presented in legal language. At the very least, a careful
> system design document, preferably with pseudo code, and a detailed
> threat model should be presented. A working model would be better.
>
This isn't a proposed cryptosystem design. It's a compilation of
minimal requirements for security. It is expected that there will be
many designs that meet the requirements. It's based on known designs,
and existing analysis.
Just as in standards development, requirements don't specify the
result.
As I tried to indicate, this is to specify the security sensitive
information, so that when folks come to testify or work on conference
papers, they are all speaking the same language. I needed your help to
ensure that we didn't miss anything important, and we don't go down the
sad course that electronic signatures suffered last year.
David Honig wrote:
> you're gonna have to educate them in security
> analysis.
This is exactly the purpose. The select committee will be designated
next week. Most legislators won't bother to be educated until there is
actual legislation to consider.
Congresscritter Rivers convened a roundtable on Internet Privacy about
5 years ago, long before most folks in Congress were considering such
issues. She went to the trouble to find local talent, such as Honeyman
and myself.
She has long displayed interest in other security issues. She's on
Science and Technology, and has a couple of major universities in her
district. Her background is biology and anthropology, so she is
capable of following scientific rationale.
I actually consider her pretty Internet savvy; however, I'm biased.
On the other hand, she finds PGP too hard to use. She wants these
requirements to be simple, low cost, easy to use, and as close to
existing election practices as possible, so that non-technical people
can comfortably use the system.
Those of you that have known me for a long time might remember that I'm
the fellow that wrote the Michigan appropriations language to provide
matching funds for NSFnet, the precursor to the commercial Internet.
I've been involved in electoral politics for going on 25 years. If you
know of others with the requisite experience in politics, legislation
and security, I'd like to meet them.
"(Mr) Lyn R. Kennedy" wrote:
> 1. An electronic election system need only be as good as the current
> system. While perfection remains the goal, the minimum criteria
> is that it be no worse.
>
> 2. There needs to be an absolute disconnect between the voter and the
> vote. Some kind of voting certificate should allow a vote but make
> it difficult to determine how someone voted.
>
I agree. Very important points.
> 3. The concept of the polling place needs to be re-examined. ...
Someday, remote absentee voting might be practical. Right now, the
goal is to gain experience in existing polling places, and remove the
restriction that military bases and foreign offices cannot be used as
polling places. There was a pilot on that last year.
> It seems that something like a smartcard would be the best scheme.
Not likely. Voting is very different from banking transactions. And
issuing smartcards with special software for voting is likely to be
prohibitively expensive.
Somebody wrote:
> It strikes me that the greatest cause of confusion in vote counting
> stems from the variation with which voters express their intent.
Yes, that's why most of the language concentrates on uniformity of
interface and presentation. The only known way to eliminate that
variation is to use an entirely digital method. Every other system
involving paper (or transcription between analog media) will have an
error rate.
Somebody wrote:
> Of course the digital signature alone cannot ensure non-repudiation.
> Maybe this should either leave out non-repudiation since it's a
> broader issue or be reworded ....
>
Good point! Exactly the eye to detail I needed. I'll move it, and
redefine to describe the term.
"Arnold G. Reinhold" wrote:
> I would much rather you specify specific technologies, such as FIPS
> standards (SHA1, SHA2, AES, (it will be out soon enough), DSA, and
> P.1363.
We cannot do that in this statute. The language has to last for
decades. The vendors will make such choices, and they will be
evaluated by the states and municipalities making purchasing decisions.
Instead, those standards will be specified by NIST, rather than the
legislature.
Let me stress the point: this is supposed to promote competition. As
long as the competitors interoperate, the specifics are beyond the
scope of an authorizing statute.
Somebody wrote:
> Hmm... perhaps a requirement that the seed be generated from a 'good'
> source; and is six months long enough? ... seems people will still be
> recounting Nov 2000 ballots in May.
>
The six months used here was to ensure enough time for the bureaucracy
to setup the information. It's actually desirable to reveal the seed
after the election, so that auditing can ensure that no elements were
faked. Six months is strong enough. I tried to avoid over-specifying.
Something to remember: actual government purchases usually include a
performance bond. That can be a real incentive to successfully meet
the requirements.
"Arnold G. Reinhold" wrote:
> I find the language "for at least six months" to be very dangerous.
>...
> And where does 6 months come from? Moore's law will cut that in half
> every Congressional election cycle anyway.
That's why all requirements are specified in time, rather than bit
lengths. The requirements have to last for decades. NIST will
evaluate the appropriate technology. Equipment will be upgraded.
Somebody else wrote:
> I think that the open-source requirement is good, but it is likely to
> be scuttled by pressure from the myriad companies that are producing
> proprietary voting systems. Most staffers would not understand why
> open-source is important. Adding more language that explains the reason
> behind it would be useful in giving it a greater chance to become part
> of any law.
>
Yes.
Note that only the election software is required to be open source.
It has to be, so that folks can verify that the list of candidates
and such is valid. Easy to do with XML, java, etc.
The underlying system can still be proprietary. Sidestepping a
landmine. Otherwise, established vendors (read M$) might vigorously
oppose it. As long as they successfully meet the security standards
and interoperate, should be no problem.
Still, there's considerable opportunity for SELinux, OpenBSD, etc.
Could be a business opportunity, "mine is more secure because it has
been audited by 100,000 eyeballs".
"Arnold G. Reinhold" wrote:
> There are a lot of reasons why open source is desirable, but it does
> simply the job for an attacker.
I disagree. Security by obscurity is never desirable.
"Arnold G. Reinhold" wrote:
> Why Base-64? The mixed capitalization will drive poll workers crazy
> and many polling places will report broken machines because the can't
> enter the password properly. Base-32 would be a much better choice.
>
Only for techies. And s/key-OTP style words are often cumbersome, but
people like things that seem like words.
Anyway, the reason is _something_ has to be chosen for
interoperability. It's a standard. It works in email.
David Honig wrote:
> How do you avoid a 'traffic analysis'-like attack where you monitor
> both the votes sent out to state DB servers and who comes out of the booth?
> This would only work on slow polling places, but would let you
> link people to their votes. A solution is to batch. Maybe not
> worth worrying about, but never a problem before networked computer
> voting machines.
>
Confidentiality requirement and penalties. Probably SSL cum TLS.
David Honig wrote:
> At which points in the system would a hacked-keyboard (like the
> keystroke recording things that go in-line, but one that changes
> votes) be detected?
>
Somebody else wrote:
> This system also doesn't meet the requirement for any voter to
> be able to verify their vote. While there is an ASCII print out of
> the vote, there's nothing that guarantees that the printout is
> the same vote as was sent to the server. The attacker in the last
> paragraph could modify the software such that it prints out
> the voter choices while actually voting the attacker's choices.
>
Some of the proposed systems print the transaction as it is sent, and
thus the voter sees what was recorded. S/he isn't sure it is really
sent. So, you need an audit requirement. The tape printout has to
be compared to the internal digital copy one transaction at a time.
The whole thing rests on the penalties that are imposed for fraud,
and a reasonable certainty of being caught.
Probably needs some testing operations language. I'll ask around.
> >(D) UNIFORMITY -- Display of candidates shall be substantially similar
> > for each race within a state. On each display, the names of
> > candidates may be randomly ordered within each race.
>
David Honig wrote:
> Randomly for each voter? Random by county? Random by race (so that
> in Presidents you see Lib/Demo/Repub but when voting for Governor
> you see Repub/Lib/Demo)?
>
Yes, yes, and yes. Some places are random by precinct.
Different states have different policies. Note the use of "shall" and
"may". Without the latter, different ordering would be prohibited.
So, it needs to be mentioned.
"Arnold G. Reinhold" wrote:
> Some states (e.g. Florida) specify order on the ballot in terms of
> party results in the last statewide election. Whether that method is
> reasonable has nothing to with electronic voting.
>
Uniformity is a legal "due process" issue that was obvious in the last
election.
Verifying election software requires that the allowed variations are
specified. A security issue.
> Election
> > software shall prevent overvote and undervote, and shall allow the
> > voter to correct such conditions. Voters unwilling to indicate a
> > choice may select "no vote". Where "none of the above" or its
> > equivalent is a valid choice, "no vote" shall be a separately
> > distinguished choice.
>
David Honig wrote:
> How about voters not willing to vote for anything in that race, *including*
> 'no vote'? Is "no vote" a radio-button default?
>
Yes, you could look at it that way. Some states allow "none of the above", so
it has to be distinguished from "left the space blank and refused to vote".
Databases need a "missing data" indication.
This is really an interoperability issue, not a security issue. But it
does speak to verifying that the election software is working, not just
leaving various races blank.
> >(E) VERIFIABILITY -- The record shall not include any other personally
> > identifiable voter information.
>
David Honig wrote:
> Yeah, why should it, the Government has the lookup table. No difference,
> if the Government is the source of the threat to anonymity. Isn't this
> part of the threat model?
>
It is.
Also, many jurisdictions have the requirement that ballots have no
personally identifying information, and will invalidate a ballot for
having stray marks on it.
> >SEC. xx20. POLLING SECURITY REQUIREMENTS
> >
> >(A) AUTHENTICATION -- Transactions registering voter choices shall be
> > authenticated by a digital certificate.
>
David Honig wrote:
> A one-time certificate which comes from a machine that's about to take your
> vote? What is the point?
>
It's not one time. It lasts the whole election. It serves to
verify that the vote came from an authorized machine.
> Another question: where is your time base from? GPS? The internet
> time servers? This matters if/when the computers use their notion of
> time to shut voting off.
>
There's no fixed notion of time. Voting is always shut off by a person
at "the closing of the polls". Often, polls stay open as long as there
are folks that lined up before the deadline.
> I don't understand your absentee ballot procedure, except that
> legacy paper is still supported via human data entry.
>
> What happens if someone forgets a PIN?
>
> To vote absentee in Calif all you need is a stamp and the ability to write
> your signature. Increasing the complexity will deter people. (Where
> did that separate letter with the PIN go?)
>
What happens when someone loses a ballot? Or the absentee ballot is
stolen?
Anyway, the absentee ballotting is the most controversial. There's
no voting at home. Only at authorized federal sites.
"Arnold G. Reinhold" wrote:
> > election system, and shall be destroyed by the local polling machine
> > at any time subsequent to the expiration of the certificate.
>
> This seems impossible to verify, especially if one plans to use
> hardware that has other uses and is therefore physically accessible
> throughout the year.
>
Here's where inspection of the software is important. Ensure that
it's overwritten and never cached. But, really, it will be the
vendor responsibility to demonstrate. Think of it as a business
opportunity.
Besides, since the certificate is no longer valid, does it matter?
The servers won't accept any more transactions....
> >(C) DUPLICATES -- When more than one authentic vote by the same absentee
> > voter is detected, the last such vote shall supercede any earlier
> > vote. An absentee voter appearing at the regular polling place shall
> > supercede any earlier vote.
>
David Honig wrote:
> Duplicate votes are not handled the way you propose ("keep the last").
> You are changing the law here I think. Besides, you could vote Gore,
> see that its a waste, and go back and vote Nader. This violates
> a 'single commit' Voting Ideal. This is what I mean by changing
> election procedure to accomodate some whizzy new tech.
>
Actually, single commit is not the ideal.
Currently, folks that request an absentee ballot, but the ballot is
lost or stolen, vote in person at the municipality, or at the polls.
But a lot of folks _would_ like absentee voters to be allowed to change
their minds. Nothing more frustrating to a canvasser than to show up
the day after someone has already sent in their ballot.
It's also a protection against coercion. If someone forces you to
vote, you can change it later.
> >(D) TIMELINESS -- Electronic absentee ballots shall be received and
> > recorded at least 24 hours prior to the opening of the polls.
>
"Arnold G. Reinhold" wrote:
> Unless there is a design issue that I don't see, that is a political
> question.
>
David Honig wrote:
> Why reject them when the polls start? Give everyone the same deadline.
> Or, what is the current policy?
>
Current policies vary all over the map.
Absentee votes need to be recorded before the election day, so that
the polling places can prevent duplicate voting, or revoke an earlier
"stolen" vote to allow in-person voting.
Absentee voting is likely to be the most controversial part.
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.1
iQCVAwUBOnOZetm/qMj6R+sxAQFH7AP+JvmMYHrfjwwYjD+7h0DKxYGa1Iuym/og
nmsHJtZT6JCJ4fI2NQVzpmKTucGrGhRRf5wIQSXkS2lmszzNK9GnshflPC0Yl0Z0
WU9zKX4tpyxiFE7YdPPOh2PzprkA/8W8SRyTXaeeR04qfC4szwEIl02H8KH3d8dw
06N58z0K7xc=
=1W/S
-----END PGP SIGNATURE-----
