[Tfug] A sense of time

[Bexley Hall]

--- jblais <joe.blais at pti-instruments.com> wrote:

> I'm doing a thing for a synthesizer, that requires
> that "messing with the
> data" can't happen (FDA and CFR stuff).  The usual
> way is to put log stuff
> into encrypted files and such.  I'm starting to use
> another way, probably
> already in use, but to me it seems new.
> 
> Anyway, the log files are completely open and easy
> to read, no write
> protection, nothing encrypted simple ASCII.  Each
> line, in my case starts
> with a floating checksum. I use about 4 bytes worth
> and display the value in
> hex code, followed by the information being logged:
> 
> 1f33a101 June 1, 2008: Keypress: Login
> ef23a722 June ... whatever...
> 
> and so on.  I just add each subsequent character to
> the next byte (don't
> allow one byte's overflow to affect the next
> checksum)  The algorithm must
> be public.  The file must be public.  Each
> subsequent file starts off with
> the last file's checksums.
> 
> I don't think that there is any way that you can't
> detect a change, that's
> really what I'm after.  Not so much to prevent - I
> can't - just detect.  If
> you delete a line, the checksum for all the
> following lines will never add
> up.  If you swap the order of 2 lines, even though
> the information contained
> doesn't change, the checksums probably will no
> longer add up.

Insert a change;
Calculate the corresponding checksum based on the
  previous line, changed line and PUBLISHED algorithm
Repeat this process for all subsequent lines

:<

Of course, *eventually* you will stop doctoring the
logs and someone will KNOW that a change has been
made -- yet they won;t know *where* it crept in
since you have dutifully "fixed" all log entries
after the modified entry that you originally made!

I exposed a vulnerability in a "key making" (think
door locks) system whereby the user/vendor could
"detect" that something MAY have happened that
was unobserved... but, it didn't help them figure
out *if* anything had happened or, more importantly,
*what* had happened!

(moral of story:  you need to actively play both
roles in these scenarios -- developer and antagonist)

> For a voting machine, the checksum and log line, and
> file information could
> be visible to the voter, every time they hit a key. 
> They could write down
> the pertinent info at the start and end of their
> voting session for their
> own reference.  Voting judges could go to a machine
> at any time and press a
> few screen changes, or some recorded no-op keys, and
> keep the log
> information for themselvers. All vote files would be
> published immediately
> on the WWW wen the doors close.  The algorithm to
> calc the checksum, and to
> interpert the keypresses (tally up the votes) would
> likewise be published.
> Just no names. Anyone could then inspect the log
> files, see where their vote
> is logged, and follow through the tally to see that
> their vote really was
> counted.  The problem is with, if someone knows you
> voted on machine A at
> 12:25, they could figure out how you voted (and fire
> you for being a
> center-winged coward, or pay you for a vote well
> planned). -- perhaps don't
> log the time, just log judges tracking entries when
> doors open and close.
> No key on the voting device could function without a
> log entry.
> 
> joe
> 
> 
> 
> 
> _______________________________________________
> Tucson Free Unix Group - tfug at tfug.org
> Subscription Options:
> http://www.tfug.org/mailman/listinfo/tfug_tfug.org
> 



       
____________________________________________________________________________________
Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. 
http://mobile.yahoo.com/go?refer=1GNXIC