Re: code validation?

From: Ron Crane <voting_at_lastland_dot_net>
Date: Tue Feb 22 2005 - 15:45:10 CST

This means that we have to trust certain people in the "official
releasing authority", especially if portions of the executable code
base are built (e.g. compiled) from the publicly-revealed sources.
Let's say that someone associated with OVC wanted to add cheating code.
If the executable code were built from the sources, it would be
relatively simple for the cheater were she to become the "build
maven" or a sysadmin to compile the cheating code (or cause it to be
compiled) into the official release. It would be more difficult, but
probably not impossible, to get cheating code into the release through
the artful use of comments, conditional compilation, and macros that
obscure its true nature and extent.

This is a strong argument for using only interpreted languages (without
self-modifying capabilities!), and also a strong argument for thorough,
well-documented review procedures. Does anyone know of any existing
procedures that address these problems? It'd be useful to have
something to start with, rather than writing it all from scratch.


> Re: "hash"
> I'm familiar with that stuff (having spent 30 years in the computer
> industry, was a consulting engineer for Digital, may it RIP).
> But I can take the code, insert my insidious
> fraudulent code, and update the hash code, then release the
> CDROM with my fraudulent code to unsuspecting precinct people,
> for instance, and the hash code will check.
> I was thinking along the lines of using public key encryption.
> If I am releasing code, I could encode the entire
> binary with my private key, and then the precinct people
> or whoever would unencode it with the public key. That way
> you could guarantee that the code that the precinct people
> are using came from me (or whoever is the official releasing
> authority).
> As far as controlling the source, I'd think that any source control
> system with restricted write access would do it.
> At 12:30 PM 2/22/2005, you wrote:
>> This raises several interesting issues. How is the software reviewed?
>> What are the standards? Who has to review it, and for what? Once
>> review is completed, what happens? Does the reviewee incorporate the
>> comments, re-test, then checkin the code to some source control
>> system? Does the reviewer re-review the result before checkin? How is
>> the source control system's security maintained? What's the chain of
>> custody between the reviewer(s) and the CD duplicator? Who are the
>> people we must simply trust not to muck with the software? How do we
>> minimize the number of trusted people?
>> -Ron
>>> Hello Paul:
>>> Try looking under the word, "hash." A hash is sort of
>>> a glorified check sum system that is ran on the
>>> original software. When the hash of the CD disk
>>> running the software is ran at startup on the voting
>>> equipment, the number generated has to be the same as
>>> the publically published originally generated hash.
>>> Additionally there would be various legal and
>>> adminstrative techniques involving multiple, intersted
>>> witnesses in the CD duplication process. Foolproof?
>>> No, but still very tamper resistant and compliant with
>>> a good risk management approach to security IMHO.
>>> HTH, Ed Kennedy
>>> --- Paul Kinzelman <> wrote:
>>>> I took a quick look back in the archives, and
>>>> couldn't find this
>>>> topic, and you folks must have thought about it
>>>> already, but please allow
>>>> me to ask it anyway...
>>>> How do you validate that the code running on a
>>>> voting machine
>>>> has not been tampered with? Have you thought about
>>>> using
>>>> public key encryption on the OS release or
>>>> something?
>>>> _______________________________________________
>>>> OVC discuss mailing lists
>>>> Send requests to subscribe or unsubscribe to
>>> =====
>>> --
>>> 10777 Bendigo Cove
>>> San Diego, CA 92126-2510
>>> Work for the common good.
>>> _______________________________________________
>>> OVC discuss mailing lists
>>> Send requests to subscribe or unsubscribe to
>> _______________________________________________
>> OVC discuss mailing lists
>> Send requests to subscribe or unsubscribe to
> _______________________________________________
> OVC discuss mailing lists
> Send requests to subscribe or unsubscribe to

OVC discuss mailing lists
Send requests to subscribe or unsubscribe to
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
Received on Sun Feb 27 17:17:10 2005

This archive was generated by hypermail 2.1.8 : Sun Feb 27 2005 - 17:17:13 CST