Secure Software License Usage Audit Log

Question

Folks,

We have an intriguing technical challenge. How to write a secure audit file that tracks usage of a software so license fees can be based on usage thereby making it more affordable to those who use it less.

Specifically, TickZoom sells a alpha generation trading platform for hedge funds which presently costs $2,000/month to license including support (will increase soon to more than double). That's fine for institutions but too expensive for individuals. Individuals often ask for a lower price in exchange for a % of the profits made using the software until they can afford to pay the fixed fees.

We like that proposal. But we need a reliable way to audit the profit actually generated on the platform and a way to prevent users from "gaming" it by deleting or overwriting the audit file thereby reporting lower earnings than actual.

This application is written in C# and this portion of the system is obfuscated at least making it difficult to decipher the code.

The other requirement is write to the file for every trade that occurs so as to allow for more in depth auditing in the event that the user feels there is some discrepancy in the total fee. That way, individual trade profits can be compared with broker statements.

It is, of course, assumed that the file will be encrypted.

But any ideas on how to make it "tamper proof"? Especially against a simple delete attempt?

My first guess is to make the software always require a preexisting audit file or it will refuse to run.

Then when we deliver the software it gets packaged with an "empty" audit file but which, in fact, has some kind of tamper-proof verification.

The next obvious technique users might try to "tamper" with the file would be for someone to simply backup that original "empty" file and later use it to overwrite the audit file later thereby fooling the system into thinking that it was a fresh start.

Perhaps that can be resolved by included some kind of "last update timestamp" and an expiration time.

Also, totally different solution ideas are welcome. We might be forced in this case to add a "phone home" ability so that trades get logged to our central server. But that seems disadvantageous and potentially adds another failure point in a mission critical application. Generally they greatly dislike "phone home" features with obvious good reasons.

Sincerely, Waynek

Answer 1

Here is a thought - whenever the user exits a session with the software, generate a hash based on the audit log. Encrypt the hash, then write it out to another file, perhaps hidden amongst your binaries, or to the registry.

When the user opens the application next, read the log file, re-generate the hash and see if it matches the recorded value. If it doesn't, shut down the application with a "Audit file tampered with" error message.

Not totally fool proof, but would be pretty solid.

Also, check out this question

Answer 2

The statement of your problem is:

• we don't trust the client; the client could be hostile.
• we want the client to send us data which we can trust.

There is no solution to this problem. You might as well say "I want to find two guys, one named Bob, one named Bill, such that Bob is a foot taller than Bill and Bill is a foot taller than Bob". You're not going to find two guys with that property.

You absolutely positively cannot trust anything that comes from a machine that you don't own that might be owned by a hostile client. My advice is do not waste your valuable time trying to solve an impossible problem; spend that time on making your server, which you do own and do trust, robust against hostile clients.

Answer 3

No, I don't believe there is anything you can do other than report all earnings in real-time back to your servers, but even that has issues.

-- Edit:

You're only options, as I see it, are:

• Convert the system to web-based (or at least thin-client), thereby making all the transactions on the server

Clearly, this is probably pretty impractical, if you're already developed an entire locally-based system

• Think up some elaborate scheme that is "hard" to break and hope people don't break it

And combine within this method, some sort of profiling that shows if the shops are earning X, and suddenly X-sigificantAmount, you can determine that they aren't even profitable any longer, thus probably cheating the system (or going out of business :) But this verges on quite an invasion of privacy, and may not be at all appropriate.

Practically, I think you'll need to weigh the risks against the possible profit, or find another angle on how to sell to these people (i.e. only let the interface/app itself manage X in total funds, if it goes over, prompt for pro version, or whatever).