What are the key features should I consider if I want to create a simple fraud proof and non repudiation system? For this question, I am mainly concentrating on the integrity of the database rows. This is not a security permission question.
Using a soccer database as an example, some of the key features that I would implement are:
-
Prevent DBA from modifying the row data using traditional SQL. For example, if the database row has already stored 2:1 as the result, if DBA changed the result to 2:3, we should be able to detect the modification. All changes should be done via the main application.
-
Prevent the copying of a row of the data to another row from using the backend changes. We should be able to detect the fraud changes.
Are there any other issues or features I should consider to make my system more fraud proof? What are the best practices that I should be aware of? Any pointers would be most appreciated.
Many thanks in advance.
Create one column which is a cryptographic signature of the other columns. So long as the ID is included in the signature computation, you couldn’t copy a row because the ID would change. No modifications could be performed without recomputing the hash, so the DBA’s change would be detectable too.
That doesn’t tackle the problem of DBAs removing rows, mind you – it only validates that each individual row went through the appropriate business logic. You could potentially include a signature for the whole table, but that starts getting pretty heavy!
Of course, at some point you need a secret – the private part of the signature key. Your code will need access to that… and whoever writes that code could include a back door to email themselves the private key etc. Sooner or later you have to trust someone, I suspect. (You could apply multiple signatures, of course, from different teams – so the teams would have to collude in order to forge anything.)