[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