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,
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.
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.
--
Kent Crispin "Do good, and you'll be
[EMAIL PROTECTED] lonesome." -- Mark Twain
