[Tfug] Let's play "ID this code"! (serious issue actually)

Bexley Hall bexley401 at yahoo.com
Mon Aug 24 17:15:54 MST 2009


> -0700, Jim March wrote:
> > > It is possible to extract the data structure of
> all tables, the
> > > lookup data that is not generated via the casting
> of votes, and
> > > all code (triggers, defaults, functions, views,
> procedures) from
> > > the database and put them all into a text file
> and generate a
> > > hash from it. And that can all be done in code.
> > 
> > Glen, that sort of thing is completely beyond the tech
> > abilities of most of the county elections officials.
>  
> My point is that the vendor *could* have provided a program that  
> performs that type of validation. That's the type of solution I 
> would look to implement if I had to hack the existing system into 
> compliance.

If you expect the vendor to do it, then you are letting the
fox guard the chickenhouse.

The purpose of these checks is so that a third party can verify
the "image" without having to *trust* any results from another
party (esp. the manufacturer who may have motivation to "fudge").

[I.e., its like the difference between open cryptosystems and
"proprietary ones" where you are told to *trust* the vendor]

E.g., a checksum on a ROM can be verified by *anyone* with
a device that can read ROMs (*most* PROM programmers can do this
though some of the fancier ones can't!  :< ) -- even if that
device itself can't compute the required hash/checksum
(the user can use thedevice to examine the ROMs contents
and compute the hash "externally").

The only industry, IME, that really takes these issues seriously
is the gam[bl]ing industry.  When *your* money is at stake, it
is amazing how much effort you will expend to protect it!  ;-)


      




More information about the tfug mailing list