Re: code validation?

From: Paul Kinzelman <paul_at_kinzelman_dot_com>
Date: Tue Feb 22 2005 - 14:27:59 CST

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 <paul@kinzelman.com> 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
>>>arthur@openvotingconsortium.org
>>
>>
>>=====
>>--
>>10777 Bendigo Cove
>>San Diego, CA 92126-2510
>>
>>Work for the common good.
>>_______________________________________________
>>OVC discuss mailing lists
>>Send requests to subscribe or unsubscribe to arthur@openvotingconsortium.org
>
>_______________________________________________
>OVC discuss mailing lists
>Send requests to subscribe or unsubscribe to arthur@openvotingconsortium.org
>

_______________________________________________
OVC discuss mailing lists
Send requests to subscribe or unsubscribe to arthur@openvotingconsortium.org
==================================================================
= 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:09 2005

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