Re: [logs] "Temperproof" logfiles?

kieranat_private

On Fri, 4 Apr 2003, Jason Haar wrote:

> On Thu, Apr 03, 2003 at 04:04:43PM -0500, Blaise St-Laurent wrote:
> > the more i think about it though, the less i think that database +
> > tamper resistance is going to be an syslog issue. If you want to sign
> > or at least put a checksum against every line that goes into your db,
> > the best way i could think of doing this is to write a trigger on
> > insert that calculates the checksum based on the values you supply
> > (time, server, msg etc..) and adds it to the appropriate column. I'm
>
> I may be showing my ignorance here, but can someone explain to me how
> checksums *by themselves* actually "prove" the data hasn't been tampered
> with?

Good question :)
>
> I mean, if I have a years worth of syslog data, md5 checksum the files, and
> burn them all off onto tape. A year later in court, I can confidently say
> that the syslog data *as it is on the tape* is as valid today as it was
> *when the tape was written* (as the checksum will hopefully match).

I took a quick look at the Peo module for msyslog.  They checksum
two text buffers, message and key.  Seems to me that this is the
"sprinkle magic crypto pixie dust" approach.

I'd guess that a per-log message checksum of the following data:

1.  Serial number (like a database primary key)
2.  Last checksum (ie checksum of message serialnumber -1)
3.  Log message
4.  Key
5.  Data and time (possibly unnecessary: many log messages will include
    this anyway)

would be more difficult to tamper with, but could still be completely
faked by an insider.  Said insider would need to fake all messages
after the tampered one though, because of the inclusion of the last
checksum.

If there were some third-party timestamping service, as well, so that a
daily timestamp were included in the checksum chain, I'd guess this
would be proof against most internal attacks, as well as external ones.
An insider _could_ tamper with messages, but would have to do so within
a particular timeframe.

(Incidentally, does checksumming service such a service exist?  Perhaps
counterpane might be interested in offering it?)

Performance would take a significant hit, of course.

> I mean, as far as legal goes, surely all that this checksumming does it
> "prove" the data hasn't been altered *since it was written*. It doesn't say
> anything about me fiddling with it before I checksumed it...
>
It's going to be difficult to avoid insertion of bogus messages, either
from insiders or external attackers.

> Surely in court, it's simply about proving your copy of the data hasn't been
> altered since it was written, and then it's *totally* a "reliability of the
> witness" type problem after that...?

At a guess, if the information structure is highly tamper-resistant,
then there will be fewer issues with chain-of-custody of evidence
questions.

Regards

Kieran
_______________________________________________
LogAnalysis mailing list
LogAnalysisat_private
http://lists.shmoo.com/mailman/listinfo/loganalysis