Re: [IFWP] Voter authentication

[Michael Froomkin - U.Miami School of Law]

To make a long story short:

1) I did indeed understand you to be worried about something other than
what you describe below.

2) If one were to decide to be worried about the problem you describe
below, the simplest solution, as you note, is to have the code running on
the trusted third party's machine, which again is really far from
difficult in today's world given the small number (<10K) of participants,
but could become a system load issue as the number grew and the
prevalance of machines.

3) In the very short term, unless there's some reason to think the people
involved in this project are more likely to be involved in fraud than
anyone else, it still strikes me as something that can wait until later.

4) I can't see any particular reason to think the risks of fraud on the
part of the volunteer vote-taker are more likely here than several other
places in these proceedings.  Which of course is the real issue.  If after
the fact someone thinks there is fraud, let them say so.

5) That said, it seems reasonable to put down a work item for some time
next year about having vote-takers who have no interest in the outcome --
and make sure that the principle applies equally to each constituency.
Plenty of higher-priority issues right now.
 
None of the above should be read as a substantive comment on the merits of
any constituency, or even the idea of constituencies, because it isn't.


On Sun, 18 Jul 1999, Kent Crispin wrote:

> On Sun, Jul 18, 1999 at 02:23:50PM -0400, Michael Froomkin - U.Miami School of Law 
>wrote:
> > Now, crypto happens to be something I know a little
> > about.... ( http://www.law.miami.edu/~froomkin/#crypto )
> 
> Very impressive.  However, crypto and network security are two very 
> different, though related subjects, and expertise in one does not 
> translate into expertise in another.  Security makes use of crypto, 

Agreed.

> but it is a very practically orientd use, not an academic one.
> 
> In any case, thank you for the opportunity to be gracious.  I will
> try not to blow it :-)
> 
> > On Sun, 18 Jul 1999, Kent Crispin wrote:
> >  
> > > Peer review of the code doesn't do the job at all, unfortunately. 
> > > How do you know that the reviewed code is in fact the code being
> > 
> > I agree that in a perfect world the system should be reistant to this.  
> > As an interim issue, it seems fairly low on the list of priorities.  Are
> > you seriously suggesting that there is a real risk of this fraud?  
> 
> Yes.  The problem is that it is *very* easy to do, and it can be done
> at any time, and in many circumstances, as I describe below, it can
> be done little fear of detection or punishment.
> 
> > In any case, proving that the code offered to the referee is the same as
> > the running code is trivially easy: you compile it, and hash the two
> > programs, and bit-compare them, or compare hashes.  (Of course you have to
> > use the exact same compiler and OS).  Ditigally sign every step for
> > long-run ease of comparison.
> 
> I must not have been clear -- apparently you completely misunderstand
> the problem.  There is no necessary relationship between a particular
> executable file on disk, and a program running in a computers memory,
> period.  
> 

Yes, I thought you were worrying about a different issue.

> More concretely: The auditors come, examine the code, certify it, and
> leave.  A *different* program starts up the minute they walk out
> the door, a program derived from the certified one, and that as far
> as the external network connection to the rest of the world behaves
> identically.  But it actually does a whole lot of other stuff, in
> addition.  When the auditors come back, they find the same certified
> code sitting on Joops disk, unmodified.  But unless they are logged
> on locally, and monitoring in real time, they can't verify that the
> program that is running, and providing service to the outside world,
> is the one they certified.
> 
> Furthermore, the trojaned version will externally act identically to 
> the certified one, so no one, an auditor or a normal voter, could 
> ever tell the difference externally.
> 
> In fact, even if you *are* sitting there, monitoring in real time,
> you can't really be sure.  It would be perfectly possible to have a
> trojaned shell that ran "election_code_subverted" whenever you
> specified "election_code_verified" on the command line, for example. 
> 
> This may seem far fetched to the inexperienced, but this kind of
> thing REALLY DOES HAPPEN, ALL THE TIME, IN THE REAL WORLD.  There are
> nicely packaged hacker toolkits, commonly available, that replace the
> system utilities that would normally reveal their presense, and it 
> takes no particular intelligence or expertise to run them.
> 
> So forget it.  The election operator can run any code whatsoever, and
> you have no way of preventing it unless you watch him all the time,
> and even there you can't *really* prevent it.  Crypto is basically
> irrelevant to this problem.  [Caveat: it would certainly be possible
> to develop a crypto based voting protocol that required deployment of
> a key infrastructure and appropriate client utilities.  This is,
> however, is a completely different matter than certifying a program,
> and has serious implications in terms of practicality and usability.]
> 
> > > used? How do you know that Joop doesn't go in and manually change the
> > > logs and the results?  Or an employee of his?
> > > 
> > 
> > This is also trivally easy to prevent: escrow copy of the ballots as they
> > come in (hold for a period of time, then destroy).
> 
> Uhm.  Sorry.  How does an external party know that the ballots have 
> not been changed *before* they have been escrowed?  If we deploy a 
> cryptographic infrastructure so that the ballots themselves were 
> signed by the individual voter, you might have a point, but that is 
> not contemplated, and it would be a rather complex undertaking.
> 
> > > A review of the system could build *some* confidence that a hacker
> > > couldn't break in and change things.  That is actually pretty far 
> > > down on my list of concerns, though.
> > > 
> > > The basic problem is this:  barring complex and totally unrealistic 
> > > cryptographic protocols, there is no way to do a secret ballot 
> > > election without a Trusted Third Party.  How do you find a TTP for
> > > the highly contentious international arena we are playing in?  
> > 
> > Easy.  Real easy.  Ethan Katsh, or Phil Agre, or some large law or
> > accounting firm that holds it pro bono.  So long as all they do is hold
> > the data, pending challenges, it won't cost them much.
> 
> As pointed out above, it is the agency doing the election that must 
> be trusted.  Escrowing contaminated logs isn't very helpful.
> 
> > Or, every day hash the file of all ballots, and digitally sign and publish
> > the hashes.
> 
> Yes, this superficially sounds like a good idea.  However, it doesn't
> buy you as much as you might think, because, given the problem I
> describe above, the *only* way to verify ballots is to go back to the
> original voter.  That is, knowledge that the logs have not changed is
> not all that useful, if the logs were bogus to begin with.  And even 
> the original voter is not necessarily enough...
> 
> Here's the scam:
> 
>   On a probabalistic (or systemative) basis, alter incoming votes in
>   such a way to guarantee the vote goes the way you want.  Log the
>   original ballots in a secret place; log the altered ballots for the
>   auditors; publish the hash, whatever...  If a voter is suspicious,
>   send them back their original ballot to show that it was received
>   correctly.  Or you may just as well send them back the altered one,
>   if circumstances dictate -- he can't prove it was you who altered
>   it. 
> 
>   In a close election there is *no* way to audit this, because *the
>   voter has no way of proving what they sent*.  You just tell them
>   that they must have made a mistake, and better luck next time.  So,
>   the election operator can *with impunity* alter close elections to
>   his advantage, as long as he doesn't do it very often. 
> 
> > > Ideally the TTP should *actually* be trusted, and neutral to all
> > > concerned, but this is very tricky.  There was, for example, some
> > > discussion of the American Arbitration Association managing the
> > > election, and we were assured that the AAA is highly respected etc. 
> > > But the fact remains that the AAA is an unknown to most of the human
> > > race, and hence, on the face of it, not trusted.  In some circles,
> > > the word "American" automatically makes it suspect. 
> > 
> > We can, however, settle for actually fair, and let them build the trust.
> > I bet we can find someone or a body with a reputation capital on a par
> > with, say, Esther Dyson (an American!).  Again, not a deity, but we are
> > all fallen are we not?
> 
> The scam I describe above can be instituted at any time. 
> Furthermore, it can be instituted as an external hack, and the even
> the election operator would never know. 
> 
> > > To summarize a potentially lengthy argument, international secret
> > > ballots over the Internet are, IMO, quite problematic. 
> > 
> > Do, make it actually fair, answer reasonable critics, and that ought to be
> > enough.
> > 
> > > [An obvious counter-example is the share-holder elections that are
> > > being held via email these days.  However, there are substantive
> > > differences: shareholder elections involve a very large voting
> > > population, the issues are not important to most shareholders, and
> > > the large shareholders who care and are decisive votes, probably
> > > don't use the Internet for voting.]
> > 
> > This is a ridiculous statement.
> 
> In what way? Is it ridiculous to say that shareholder elections
> involve a very large voting population, or that a large voting
> population vs a tiny voting population is a substantive difference?
> Or is it ridiculous to say that in most shareholder elections the
> vast majority of shareholders don't even bother to vote, or just sign
> over their proxies? Or that very large shareholders are unlikely to
> use email to vote their shares? Is it ridiculous to say that there
> are substantive differences between shareholder elections and the
> IDNO election process, or the discussed ICANN election process?  
> 
> *What* was ridiculous?
> 
> > The issues are important, lots of money
> > changes hands, and if anything goes wrong, esp. fraud, the people running
> > it can go to jail.
> 
> I didn't say the issues weren't important.  I said the majority of
> voters in the election don't care. 
> 
> >  So there's a very powerful incentive to make it not
> > just right, but provably right.  So this is a far more powerful example
> > that you admit.
> 
> Given the sparse nature of your response to what I said, I would
> be interested to see your basis for that statement.  
> 
> In fact, I believe it works because the voter *agrees* to participate
> in an email election, and thus absolves the election official of all
> the problems concerning email elections, and that "provability" has
> nothing to do with it.  But I confess I don't know.  I do know that
> they have absolutely no practical way of proving who actually filled 
> in the ballot -- they don't ask for a password, even, they just send 
> you a ballot and wait for its return...
> 
> > A better statement would have been, that most of these elections use some
> > sort of paper (or at least external e.g. via broker) validation of the
> > voter, since elaborate systems exist to show who can sell the share,
> > piggybacking voting on it is less hard than a system where members don't
> > have to buy in.
> 
> Validation of the voter, yes.  Validation of the vote, no.
> 
> > > However, if you drop the secret ballot requirement, and go to the
> > > Internet equivalent of open roll call voting, such as is used in
> > > Congress or other deliberative bodies (and that people demand of
> > > ICANN), these problems are greatly reduced, and some are effectively
> > > eliminated. 
> > 
> > True, but secret balloting problems while quite real are not as enormous
> > as you make it sound.
> 
> I'm glad you realize that they are "quite real".  I also understand
> that, though you play one on TV, you aren't really a cryptographer. 
> Neither am I, and I don't even play one on TV.  More important, I
> understand that you are not a computer scientist, and that network
> security is not your area of expertise.
> 
> The question is, if I were working for Joop, could I put in such a
> trojan? The answer is unquestionably yes.  It's not very hard at all,
> and if I was going to do it, I would let several elections go by
> untouched before I started tinkering with them.  Furthermore, I could
> do it in a way that Joop would never know, and would firmly believe
> that his code was certified by whoever wanted to do it.  
> 
> Incidentally, If one wanted to go to a *lot* of work, it could be
> done in such a way that it couldn't be detected in the source,
> period.  See
> 
> http://www.cs.umsl.edu/~sanjiv/sys_sec/security/thompson/hack.html
> 
> for an entertaining and classic paper on the subject.
> 
> 

-- 
A. Michael Froomkin   |    Professor of Law    |   [EMAIL PROTECTED]
U. Miami School of Law, P.O. Box 248087, Coral Gables, FL 33124 USA
+1 (305) 284-4285  |  +1 (305) 284-6506 (fax)  |  http://www.law.tm
                    -->   It's hot here.   <--