Creating a simple Non repudiation/fraud proof system

Question

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:

1. 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.

2. 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.

Answer 1

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.)

Answer 2

To be perfectly blunt: you're wasting your time.

DBAs have the equivalent of root access to your database. If not, they're going to be rather ineffective. The same issues arise with system administrators and basically anything you can do is little more than a placebo at best. The only thing you can do about A malicious person with that level of access is not give them the access to begin with.

The best you can do is make it a little harder by creating an audit trail. Log when users log in, log out, what they do, what events the system responds to and so on. The only real value of this is being able to (hopefully) reconstruct what happened if you manually decide to go in and look at it later.

As for changing the result of a soccer match, ask yourself how likely that is to happen. Of course it doesn't actually change the result of the soccer match. It simply change how it was recorded. Anyone who saw it or participated will be aware of the actual result so what value is there in someone changing it on the system?

In companies, error and malice and handled by reconciliation processes. A stockbroker will have a team that runs reports on what's on the system and compare it to bank transactions actually done. Any discrepancies get red flagged. So you could change your balance on the system but it will get backed up.

The other part of this puzzle is that restrictions on DBA activity won't actually solve the problem. Application developers can release arbitrary code. Even if it's reviewed the system can still break down at build engineers or someone with root-level access to the production environment compiling a modified version and running that.