On 18 July 1999, Kent Crispin <[EMAIL PROTECTED]> wrote:
>
>> 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.]
This is a little far-fetched Kent. First of all, it does NOT happen
"ALL THE TIME, IN THE REAL WORLD." And if you'd like to debate this
particular point, feel free. I'll start by referring you to things
like the USENIX Security Conference proceedings, and work from there.
I might not be employed currently in a computer-security capacity, but
I can assure I know enough to call shenanigans on that particular
claim. If you want to push this point further, I can put you in touch
with, say, folks at NAI, folks working tiger teams on the east coast,
etc. for real-world data. Hell, I could probably dig up some of the
better-known purveyors of these attacks and get them to give you a
feel for how often this happens. However, unless you want to move
this conversation over to Bugtraq, I don't recommend you push this
FUD further.
Secondly, most of your scenario above assumes zero trust of the person
running the elections. I will state right now that, unless there is a
trusted third-party that can run the elections (If you'll recall, I've
already asked that this happen, to no avail), SOMEONE is going to come
up with this argument. It's a straw man. No matter what you do, the
above will always be a valid argument from someone's point of view,
because there will always be an "evil sorcerer" sitting behind the
curtain, pulling the strings, manipulating reality. For further
reference, see Descartes. At some point, you must draw the line and
place some initial faith in the person running the system, and the
system itself.
Period.
Otherwise, every system out there has already been compromised, and is
just running an incredibly convincing trojanned version of the shell,
OS, scheduler, etc.
Now, if you'd like to debate security matters in a more realistic
world, I'm more than willing.
--
Mark C. Langston Let your voice be heard:
[EMAIL PROTECTED] http://www.idno.org
Systems Admin http://www.icann.org
San Jose, CA http://www.dnso.org
