|proof something happened |
Ensuring integrity of data
| 8:46 pm on Apr 13, 2010 (gmt 0)|
I'm archiving a lot of logs, dozens per day. Daily I have a PHP script that creates an MD5 hash of each file and parks all that data in a MySQL database. I'm looking for a method to ensure the data hasn't changed at some future point in time. i.e. Myself or someone else didn't go modify the original logs. The MD5 is a start, but a neferious person could make whatever modifications they needed, take a new hash of the modified file, and replace the original with the replacement.
The best idea I have is to upload the hashes to a system that I can write new data to but not edit/modify. There is still the possibility that whoever runs that system could cooperate with me to make the modifications needed.
I kinda consider this as a reverse "proof of life" problem. Rather than show something existed at after a certain time, I'd like to prove it existed before a certain time. Does anyone here have any ideas for a system that would allow this?
| 12:50 pm on Apr 14, 2010 (gmt 0)|
it probably depends on who you are trying to prove it to, what would be an adequate type of proof
you could store the md5 outside of the system so that it can't be tampered with.
nothing is uneditable
again, depending on what you are trying to prove to whom there may be a completely different option. It sounds like you are trying to establish poor man's copyright.
| 3:55 pm on Apr 15, 2010 (gmt 0)|
I'm not looking to do a "poor man's copyright", but would like to replicate that same goal.
I'm saving logs that may be used in future legal matters and I'd like to be able to prove that I didn't or couldn't have tampered with them.
| 4:14 pm on Apr 15, 2010 (gmt 0)|
|I'd like to be able to prove that I didn't or couldn't have tampered with them. |
This is nearly impossible on a computer, outright. You'll have to just do the best you can.
If you're saving these logs (data) to a DB regularly... I'd recommend just doing an MD5($data) for each log as it goes into the DB. This will give a unique identifier of the content. If the data changes at all (even just adding 1 space or removing 1 character), the MD5 will change! So the MD5 will be useful as a means of "proving" if it has been changed. Simply store the initial MD5 somewhere. When it comes to verify/prove... get the data out of the DB, run an MD5; and check this current MD5 against the original. Match = no changes; if it doesn't match, it indicates the log/data changed!
From a legal point of view... if you wanted to change the logs, you could... then generate the 'new' MD5 and replace the 'original' (making it appear it hasn't changed). I'm guessing this is the part you're having issues with.
What I would consider doing... is setting up a separate, 3rd party server with its own DB. One that you are only able/allowed to 'insert' and 'select' from. When a log is created and you get the MD5... send the MD5 over to this other server and 'insert' the record. It would be useful to include pertinent info with the MD5, such as: who submitted it (username? and full name?), when they submitted it, IP, host, etc.
Because you can only 'insert' and 'select' --- it means you'll only be able to "add" and "retrieve"... not to modify, the MD5 values. This is about the best you can do.
What would make it ~somewhat~ legally viable (though everything is up to a fight) is that the values are handled/stored by a 3rd party (not you)... which removes you from direct access (ie: it is easier for you to be claimed to have manipulated values if the values are stored on your own server, cause you have direct/full access). Secondly, by only allowing 'add' and 'get' functionality, it means you can claim: i had no right or ability to modify or remove. And since it should be a 3rd party, you'll have the other party involved on this ground. Perhaps for "redundancy"... you could catch copies of the MD5 on your server, using the 3rd party as means of "auditing" the MD5s.
But it is otherwise going to be hard to do what you want in any kind of legal sense. If this is a serious legal issue, I'd advise you to consult legal counsel! (who have experience/knowledge in such technical matters that pertain to your particular circumstance)
In addition to having MD5s on the separate server... you could also consider saving the original log there as well. This would prove useful for 'auditing', in that you'll have: a direct copy of the log; and the original MD5.
| 6:28 pm on Apr 15, 2010 (gmt 0)|
That's what I though. I guess the best I can do is park the MD5 hashes on a server/database I only have 'insert' and 'select' rights on. Thanks for the suggestions.